Nous avons récemment obtenu une Docking Station FD1006C de chez Inateck, l’occasion pour nous de vous faire découvrir ce boitier bien pratique et quelques-unes de ses fonctionnalités.
II. Le produit
Pour rapidement le décrire, il s’agit d’un boitier pour disque dur qui aura pour vocation de les rendre portables, puisque la plate-forme est faite pour être transportée. Dans cette station d’accueil pour disque dur, vous pourrez rendre vos disques durs 3″5 et 2″5 mobiles et rapidement utilisables. Voyons cela de plus près :
Ce genre de boitier peut avoir une utilité dans plusieurs contextes :
Lors de la récupération d’un système, par exemple lorsqu’une machine ne fonctionne plus, il peut être intéressant de pouvoir récupérer ce que contenait son disque dur. Le boitier permet de rapidement changer le disque dur qu’il contient, ce qui rend l’opération assez rapide.
Rendre un disque dur mobile, il arrive parfois que l’on se retrouve avec des disques durs tout seul sans pouvoir les utiliser, cette station d’accueil permet alors de redonner de l’utilité à ces disques durs afin de pouvoir les utiliser dans un contexte de mobilité ou sur un poste fixe.
La station d’accueil est donc livrée avec une alimentation et un câble USB 3.0, ce dernier permettant un débit de transfert optimal entre votre PC et le disque dur qui se trouve dans la station d’accueil :
Éléments fournis avec le FD1006C
L’avantage du support de l’USB 3.0 est que celui-ci permet d’atteindre des vitesses de transfert allant jusque 5 Gb/s théorique.
Un petit mot sur l’ergonomie du boitier, il est de couverture noire, ce qui le rend assez discret pour être positionné sur un bureau à côté d’un PC par exemple. On trouvera un couvercle coulissant permettant, une fois enlevé, de positionné notre disque sur 3″5 ou 2″5 à l’intérieur :
Ouverture du capot du boitier FD1006C
En dessous de la station d’accueil, nous trouverons quelques nervures permettant une dissipation de la chaleur produite par les disques durs mécaniques. Pour insérer notre disque dur, il nous suffit donc d’ouvrir le boitier en coulissant la partie supérieure vers l’arrière comme ci-dessus, puis d’y insérer le boitier SATA :
Ajout de disque dur HDD ou SSD au format 2″5 ou 3″5 dans le boitier
Une fois le boitier inséré, un 2″5 dans mon cas, on peut refermer le boitier :
Refermeture du capot du boitier FD1006C
Il suffira ensuite de brancher le câble d’alimentation et le câble USB3 pour y avoir accès.
Note : Il est fourni avec cet ensemble un carré de mousse afin d’éviter que les disques durs 3″5 n’aient de jeu et bougent.
Enfin, le boitier est décrit comme “dust-proof”, c’est-à-dire qu’il protège de l’environnement extérieur et notamment de la poussière.
III. Support de la technologie UASP
La particularité de ce boitier pour disque dur est qu’il permet la prise en charge du protocole UASP qui permet d’accélérer les transferts via une utilisation optimale de la bande passante. Combiné à un disque SSD et à l’utilisation de l’USB 3.0, cela permet des débits de transfert assez intéressants. Il s’agit en fait de l’équivalent du Serial Attached SCSI pour les disques durs SCSI, l’important à retenir étant qu’il s’agit d’une évolution des méthodes et techniques de transfert de données et d’informations afin de maximiser les performances.
Attention cependant, bien que la station d’accueil pour disque dur FD1006C soit compatible avec les systèmes Windows XP, Vista, 7, 8 et 8.1 (32 et 64 bits) et Mac, les apports de la technologie UASP ne pourraient être visibles que sur Windows 8, Linux à partir de la version de noyau 3.15 et OS X à partir de la version 10.7.4, qui sont les versions gérant l’UASP. Le boitier restant parfaitement utilisable pour les versions d’OS ne gérant pas l’UASP .
Voici les spécificités précises des disques durs pris en charge :
Disques durs SATA 2.5 ” /3.5 “
HDD ou SSD
SATA I/II/III
Jusqu’à 6To avec une table de partition GPT
IV. Les performances
Pour mesurer les performances, j’ai réalisé quelques tests avec le logiciel CrystalDiskMark, en voici une synthèse :
Performance en Mo/s
J’ai donc effectué un test comparatif avec un SSD et un disque dur 7200tr/min. On voit donc naturellement une différence de performance et, dans les deux cas, des performances intéressantes.
Pour conclure, ce boitier est assez ergonomique et rendra bien des services aux personnes ayant besoin d’un support pour un disque dur inutilisé, ou pour récupérer les données d’une machine qui ne fonctionne plus. Le support de différentes technologies comme UASP et USB 3.0 le rend particulièrement intéressant pour le transfert de gros volume important de fichier.
Ce n’est pas la première fois que l’on entend parler de la notion de “Windows à la demande”, Microsoft pourrait proposer l’accès à son système d’exploitation Windows de la même manière qu’Office, avec Office 365.
En avril 2014, l’idée avait déjà fait surface puis le réseau professionnel LinkedIn affirmé pendant l’été que le projet “Windows 365″ se présenterait comme « une plateforme hébergée permettant aux utilisateurs de se connecter au sein de leur propre OS personnalisé depuis différents terminaux ».
Accéder à son poste de travail depuis n’importe quel périphérique à travers une connexion internet, est-ce qu’il s’agit du prochain projet en matière de Cloud envisagé par Microsoft ?
L’avenir nous le dira, en tout cas la société Microsoft vient de déposer la marque “Windows 365“. Est-ce pour protéger son futur produit ? Est-ce une tactique défensive pour éviter qu’une entreprise tierce “pique” cette marque ? Pour l’instant, les motivations de Microsoft ne sont pas claires du tout, il faudra patienter pour en savoir plus…
Écrit en Python, Ansible est un outil Open Source qui permet l’automatisation de tâches. Grâce à lui, vous pourrez gérer vos configurations de serveurs plus facilement, et de façon automatique grâce à l’exécution de tâches sur des groupes d’hôtes.
Il n’utilise pas de client, d’agent, sur les hôtes clients mais nécessite uniquement une partie serveur Ansible, forcément sous Linux.
Par ailleurs, Ansible peut éventuellement être utilisé à des fins de contrôle, par exemple pour s’assurer que certains services soient exécutés sur un groupe de machine.
Sachant qu’il est possible de développer ses propres tâches grâce aux langages YAML, vous pourrez dompter vos serveurs comme bon vous semble avec Ansible !
Il est à noter qu’une interface graphique est disponible pour l’outil, mais c’est un outil commercial nommé Ansible Tower. Si vous souhaitez visualiser une vidéo de présentation de cette interface :
Ansible et Windows
Il faut savoir qu’Ansible ne peut pas s’installer sur Windows, même en passant par Cygwin. Autrement dit, le « serveur » Ansible doit forcément être sous Linux, Debian 8 dans cet exemple. Cela n’empêche pas qu’avec Ansible, il est possible d’automatiser certaines tâches sur des serveurs sous Windows, pour ma part sous Windows Server 2012 R2.
D’ailleurs, nous n’utiliserons pas SSH comme cela est le cas lorsqu’on administre des serveurs Linux avec Ansible, simplement car Windows ne connaît pas SSH. Il a son propre module d’administration à distance en ligne de commande : WinRM (Windows Remote Management).
Voici le schéma de l’infrastructure utilisée dans le cadre de cette mise en place :
En résumé : un serveur Ansible (JESSIE-01), un serveur Active Directory (SRV-AD01) et un serveur Windows classique membre du domaine (SRV01). Les serveurs Windows sont dans le domaine it-connect.fr.
Le fichier de configuration d’Ansible est : /etc/ansible/ansible.cfg.
II. Différence entre Ad Hoc et PlayBooks
Pour le moment, ces deux termes vous sont étrangers, et pourtant, ils sont au cœur de l’utilisation d’Ansible. Ils permettent tous les deux d’exécuter des actions sur les hôtes clients, voici on peut les définir :
- Ad Hoc :
Exécuter des commandes rapides à partir du binaire ansible. Par exemple, exécuter une action simple qui consiste à redémarrer 10 machines de votre infrastructure (administré par Ansible).
- PlayBooks :
Exécuter des actions à partir du binaire ansible-playbook. Un Playbook est écrit en YAML et permet de réaliser des actions plus complexes.
Le fait que les playbooks soient écrit en YAML, rend le code facilement lisible et compréhensible, on parle généralement de code « human readable ».
Des exemples de PlayBooks sont accessibles sur le GitHub d’Ansible : Ansible Examples
Nous verrons au sein d’un ou plusieurs autres articles les PlayBooks en détails.
Finalement, avec les « actions Ad-Hoc » vous pourrez faire des choses basiques alors qu’avec les « actions PlayBooks » vous pourrez effectuer de la véritable automatisation avancée. Les deux sont intéressants mais les PlayBooks sont la véritable force d’Ansible.
III. Préparer les hôtes Windows
Sur les hôtes Windows qui vont être domptés par Ansible, il est nécessaire de configuration la gestion à distance par WinRM. Pour cela, il faudra :
– Activer et configurer WinRM
– Autoriser WinRM dans le Pare-feu
A. Configurer WinRM pour Ansible
Pour configurer WinRM sur votre serveur afin de permettre la connexion depuis Ansible, deux solutions :
– Effectuer une configuration manuelle
– Utiliser le script d’auto-configuration fournit sur le site Ansible
Pour le premier cas, appuyez-vous sur notre tutoriel sur la configuration de WinRM, et veillez à activer l’authentification basique. Comme je suis sympa avec vous, voici les commandes pour l’authentification basique (à exécuter dans une console PowerShell) :
winrm set winrm/config/client/auth '@{Basic="true"}'
winrm set winrm/config/service/auth '@{Basic="true"}'
Dans le second cas, utilisez un script PS1 (PowerShell) fournit directement par la communauté Ansible afin de configurer WinRM :
Exécutez ce script sur chacun de vos serveurs hôtes.
Si nécessaire, modifiez la politique d’exécution de script :
Set-ExecutionPolicy Unrestricted
Pour WinRM c’est OK, il reste la règle dans le pare-feu de Windows à créer.
B. Autoriser WinRM dans le pare-feu Windows
Pour le pare-feu Windows, nous allons autoriser le port 5986 TCP. Vous devez appliquer la règle sur un profil du Pare-feu, en général dans un environnement d’entreprise, les serveurs seront dans un domaine et donc la règle devra être créée sur le profil « Domain ».
Sinon, utilisez « Any » pour tous les profils ou encore « Public » pour le profil public.
Note : Si vous utilisez un logiciel anti-virus spécifique sur votre serveur, il se peut qu’il joue le rôle de pare-feu, à la place du pare-feu intégré à Windows. De ce fait, il faudra créer une règle directement dans cette application.
WinRM configuré, WinRM autorisé dans le pare-feu, du côté des hôtes Windows c’est terminé pour le moment. Passons à la configuration d’Ansible.
IV. Installer Ansible sous Debian 8
Ouvrez un terminal sur votre Linux, Debian Jessie pour ma part, et commencez par installez python-pip qui va être utile pour installer Ansible et pywinrm.
pywinrm : Librairie Python pour utiliser WinRM.
Saisissez les trois commandes ci-dessous pour installer python-pip, puis à l’aide de pip installer ansible et pywinrm.
Ansible est désormais installé, bravo ! Passons maintenant à la création du fichier hosts.
V. Fichier hosts : Ajout des clients Windows
Le fichier hosts est utilisé pour définir l’ensemble des groupes d’hosts que vous souhaitez administrer. Dans le répertoire « /etc/ansible », créez ce fichier et éditez-le avec un éditeur.
nano /etc/ansible/hosts
Note : Si vous désirez changer le nom du fichier hosts, cela doit se modifier dans le fichier de configuration ansible.cfg, avec la directive hostfile.
On commence par définir un groupe d’hôtes, pour cela on doit indiquer un nom de groupe entre crochets, comme ceci :
[windows]
Ensuite, nous allons renseigner nos deux hôtes Windows au sein de ce groupe, ce qui donnera l’ensemble suivant :
Les lignes qui commencent par # sont des lignes commentées. Il faut savoir également que les lignes vides sont ignorées.
Enregistrez et fermez le fichier, nos hôtes clients sont désormais référencés dans Ansible.
VI. Créer un fichier chiffré avec ansible-vault
Avec Ansible, chaque groupe du fichier hosts doit avoir un fichier YML correspondant. Ce fichier permet de définir un ensemble de paramètres utiles pour se connecter sur ces hôtes. De ce fait, il contient un mot de passe connexion… Ce n’est pas très sécurisé de créer ce fichier YML en clair sur notre serveur.
Les développeurs d’Ansible l’ont bien compris, il est possible de chiffrer le fichier YML. C’est ce que nous allons faire pour le fichier correspondant à notre groupe « windows ».
Ces fichiers YML liés aux groupes sont stockés dans le répertoire « /etc/ansible/group_vars/ », que vous devez créer s’il n’est pas présent :
root@JESSIE-01:~# cd /etc/ansible/
root@JESSIE-01:/etc/ansible# mkdir group_vars
root@JESSIE-01:/etc/ansible# cd group_vars/
Pour créer un fichier YML chiffré, nous allons utiliser la commande « ansible-vault ». Avant de créer ce fichier, un réglage système doit être effectué.
A. La variable EDITOR
Pour éditer ce fichier il faut un éditeur de texte tel que Vim, pour récupérer le chemin vers le binaire de votre éditeur Ansible s’appuie sur la variable d’environnement « EDITOR ». Il se peut que cette variable soit déjà configurée sur votre machine, dans ce cas vous devriez obtenir un retour en affichant son contenu :
echo $EDITOR
Si vous obtenez un retour vide, votre variable est vide. Nous allons éditer le fichier « /root/.bashrc » pour remplir automatiquement le contenu de cette variable au redémarrage du système :
export EDITOR='/usr/bin/vim'
Il semblerait que Vim soit nécessaire car avec Nano cela ne fonctionne pas. Si besoin de l’installer :
apt-get install vim
Si vous ne réalisez pas cette étape et que cette variable d’environnement est vide, cela générera l’erreur suivante dans Ansible :
ERROR: [Errno 2] No such file or directory
B. Création du fichier YML chiffré
La commande « ansible-vault » associée à l’option « create » permet de créer un nouveau fichier YML chiffré. Le nom du fichier doit correspondre au groupe d’hosts auquel il doit s’appliquer.
Par exemple, notre groupe d’hosts « windows » doit avoir un fichier YML nommé « windows.yml ».
Ces directives correspondent respectivement à l’utilisateur de connexion, son mot de passe, le port d’accès et le mode de connexion. Vous remarquerez que ces directives contiennent l’expression « ssh » malgré que ce soit pour WinRM dans ce cas précis.
Note : Le port 5986 est le port utilisé par WinRM pour les connexions HTTPS
Sauvegardez votre fichier.
Note : Par défaut, le fichier sera chiffré en AES 256 bits. Vous pourrez vérifier que son contenu est correctement chiffré en tentant de le lire.
Pour éditer un fichier de configuration existant, on utilisera l’option edit à la place de create :
La commande ci-dessus permet d’éditer un fichier YML à tout moment afin de revenir sur une configuration.
VII. Correction du bug « send_message() crashes with https »
A l’heure actuelle, une erreur de développement est présente au sein winrm.py, un fichier Python utilisé par Ansible. Pour corriger ce bug, il faut éditer le fichier suivant :
lib/ansible/runner/connection_plugins/winrm.py
Modifiez la ligne :
err_msg = str(exc.args[0])
Par la correction suivante :
err_msg = str(exc)
Retrouvez le ticket du Bugfix sur le GitHub d’Ansible (#8720).
Cette erreur se produit lorsque l’on tente une communication entre Ansible et un hôte Windows par WinRM (chose que nous n’avons pas encore effectuée).
VIII. Tester la communication avec « win_ping »
Le module « win_ping » est intégré au core d’Ansible, il permet de tester la communication entre l’hôte Ansible et les hôtes d’un groupe Windows. Il n’effectue pas un ping ICMP, mais test le canal de communication entre les deux parties.
De ce fait, nous allons utiliser ce module pour tester la communication entre Ansible, et les deux hôtes sous Windows Server 2012 R2. Exécutez la commande suivante :
ansible windows –m win_ping --ask-vault-pass
On indique « windows » car il s’agit du nom que l’on a donné à notre groupe (dans le fichier hosts), Ansible cherchera automatiquement le fichier windows.yml. L’option « –ask-vault-pass » est nécessaire pour que l’on soit invité à saisir le mot de passe de protection du fichier.
Vous l’aurez surement compris, l’option « -m » permet d’indiquer le nom du module à charger.
Ansible arrive à communiquer avec vos serveurs Windows, via WinRM ! Si l’on veut aller plus loin dans cette initialisation, on peut même utiliser le module « setup », comme ceci :
ansible windows –m setup --ask-vault-pass
Le module setup : présent dans le core d’Ansible, il permet d’obtenir des informations basiques sur les machines cibles. Certains PlayBooks l’utilisent car les informations qu’ils récupèrent sont intéressantes pour bien identifier une machine.
On obtiendra des informations comme la version précise de Windows, le nom FQDN de la machine, le nom de l’hôte, ou encore la famille de l’OS.
Dans ce cas précis, voici la sortie que j’obtiens avec le module setup :
Pour terminer, nous allons créer notre premier PlayBook et l’utiliser par la suite. L’objectif sera de créer un PlayBook qui exécute un script PowerShell sur les hôtes Windows.
Dans le cas de cet exemple, nous ferons très simple, le script va démarrer le service Windows Update sur l’ensemble des serveurs.
– Créer le répertoire « files »
Commençons par créer un répertoire nommé « files » qui servira à stocker les fichiers annexes, comme le fichier PowerShell (.ps1), par exemple.
root@JESSIE-01:~# cd /etc/ansible/
root@JESSIE-01:/etc/ansible# mkdir files
root@JESSIE-01:/etc/ansible# cd files/
– Créer le script PowerShell
Dans le répertoire « /etc/ansible/files », créez un fichier PowerShell nommé « script1.ps1 » et ajoutez ce contenu :
Start-Service -Name wuauserv
Il s’agit d’une commande PowerShell qui permet de démarrer un service, en l’occurrence le service Windows Update nommé « wuauserv ».
– Créer le PlayBook
Pour la création du PlayBook, créez-le dans le répertoire « /etc/ansible ». Pour ma part, je le nomme « service-wu.yml » – indiquez bien cette extension correspondante aux fichiers YAML.
Note : Si vous le souhaitez, vous pouvez chiffrer également vos fichiers de PlayBook avec ansible-vault.
Au niveau du contenu, voici ce que vous devez indiquer dans ce fichier :
Note : Les espaces au début de ligne sont très importants. Sans cette indentation, le PlayBook ne fonctionnera pas et retournera une ou plusieurs erreur(s) de syntaxe.
On indique un nom général pour le PlayBook par l’attribut « name » et on précise qu’il s’applique aux hôtes du groupe nommé « windows ».
Le fait de mettre l’attribut « gather_facts » sur false, permet d’indiquer explicitement que l’on ne souhaite pas effectuer une collecte d’informations initiales auprès des machines cibles.
Nous définissions notre tâche, qui est unique dans le cas de ce PlayBook, mais il peut y avoir des PlayBooks multitâches et nettement plus complexe. Pour cela, on indique « tasks: ».
Après avoir nommée cette tâche avec l’attribut « name » (attention à l’indentation), on utilise l’attribut « script » pour indiquer le chemin vers notre script PowerShell.
– Exécution du PlayBook
Tout est prêt, nous allons pouvoir exécuter ce fameux PlayBook « service-wu.yml » ! Au sein de la ligne de commande Linux, exécutez ceci :
ansible-playbook service-wu.yml --ask-vault-pass
Vous remarquerez que l’on utilise la commande « ansible-playbook » comme il est question d’exécuter un PlayBook. On précisera une nouvelle fois « –ask-vault-pass » pour que l’on nous demande le mot de passe nécessaire au déchiffrement du fichier .yml de configuration des hôtes Windows (windows.yml).
Voici le retour que vous devez optionnel (si tout se déroule correctement) :
On remarque que la sortie est organisée en trois zones principales :
– PLAY [Run powershell script] : On indique que l’on commence le PLAY nommé « Run powershell script », ce qui correspond au nom que nous avons indiqué dans le fichier YAML.
– TASK: [Start Windows Update] : On indique que l’on entre dans l’exécution de la tâche nommée « Start Windows Update », et pour chaque hôte on indique un résultat.
– PLAY RECAP : Récapitulatif au niveau des actions effectuées, avec l’état pour chaque hôte. Il s’agit d’un résumé global pour l’ensemble du PlayBook.
Ce tutoriel est désormais terminé, j’espère que vous trouverez un intérêt à utiliser Ansible pour l’automatisation de tâches sur des serveurs Windows. Si vous avez des questions, vous pouvez venir en discuter dans notre forum directement.
Lorsque l’on commence à beaucoup travailler sur des machines et des serveurs Linux, il est intéressant de savoir comment limiter la bande passante. Cela peut être utile dans différents contextes, dans le cadre d’un serveur ou d’une infrastructure mutualisés par exemple ou juste pour éviter qu’un téléchargement ou une application prenne l’ensemble du trafic au détriment des autres utilisateurs du réseau. On pourrait très bien mettre de la QoS ou d’autres technologies, mais les outils que nous allons voir ensemble ici permettent d’effectuer une limitation de la bande passante utilisée très simplement et rapidement sous Linux, j’ai nommé wondershaper et trickle.
II. Limiter la bande passante par interface avec wondershaper
wondershaper est un petit outil, léger et très simple qui n’a qu’une seule fonction : limiter la bande passante qui peut être utilisée par une interface réseau donnée de notre machine Linux. On peut en effet limiter la bande passante entrant (download) et la bande passante sortant (upload) avec des valeurs différentes et avoir un paramétrage différent par interface.
On commence par l’installer, pour les machines Debian et Ubuntu :
apt-get install wondershaper
Pour les machines CentOS/RHEL :
yum install wondershaper
L’utilisation de cette commande est des plus basique, voici la syntaxe générale :
Il faut bien noter ici que les limites sont à inscrite en kilobits par seconde et non en kilooctets comme il est plus courant de le faire. Pour limiter la bande passante à 1Mo/s par en download et 200Ko/s en uload sur l’interface eth0 par exemple :
wondershaper eth0 8192 1600
1 mégaoctects étant égale à 8192 kilobits et 200Ko/s à 1600 kilobits. Il existe des convertisseurs très efficace sur le net, voici celui que j’ai utilisé pour ma conversion : Bit Calculator
On peut ensuite faire un test, par exemple en téléchargeant une archive depuis internet pour voir que la bande passante est bien limitée.
Il est à noter que l’on peut très bien, si l’on dispose de plusieurs interfaces, laisser les autres interfaces sans limitations ou au contraire, en mettre des plus ou moins restrictives en utilisant la même syntaxe. Il nous suffira juste pour cela de changer le nom de l’interface dans la commande utilisée.
Pour faire sauter toute restrictions sur une interface donnée, on va simplement utiliser la ligne de commande suivante, par exemple pour l’interface “eth0″ :
wondershaper clear eth0
L’interface désignée n’aura alors plus aucune restrictions.
III. Limiter la bande passante d’une commande avec trickle
Bien qu’il agisse également sur la limitation de la bande passante en upload et en download, trickle correspond à d’autres contextes d’utilisation puisqu’il ne s’applique que lors de l’utilisation en ligne de commande, c’est à dire de façon ponctuelle. Si je souhaite télécharger une archive sur internet et que je souhaite limiter la bande passante utilisée par ce téléchargement, je peux utiliser trickle pour limiter la bande passante. On commence par l’installer avec les lignes de commandes suivantes, pour Debian/Ubuntu :
apt-get install trickle
pour les machines CentOS/RHEL :
yum install trickle
On peut ensuite l’utiliser, il suffit pour cela de faire précéder notre commande de la limitation que l’on souhaite effectuer. Par exemple si je veux télécharger l’archive du dernier WordPress en limitant la bande passante utilisée en download à 10 Kilooctets par seconde :
Je vais alors voir le téléchargement s’effectuer normalement, mais la bande passante sera limitée à 10Ko/s. Je peux également effectuer une limitation sur l’upload indépendemment avec l’option “-u” au lieu de “-d” ou alors les deux en même temps :
Ici, je vais envoyer une archive via scp sur un serveur distant et la bande passante en upload ne pourra pas dépasser 20 mo/s, la bande passante en download ne pourra excéder 10mo/s.
C’est une limitation qui prendra fin dès que la commande sera terminée.
Si l’on ne souhaite pas saisir notre limitation à chaque fois que l’on saisi une commande, on peut utiliser trickle en mode démon. On va commencer par lancer le démon en indiquant notre limite de bande passante, par exemple, 50mo/s en download et pas de limitation en upload :
trickled -d 20
puis on va juste saisir “trickle” avant chaque commande sur lesquelles nous souhaitons appliquer cette restriction :
trickle wget https://fr.wordpress.org/...
Si la même commande est lancée sans “trickle” devant, aucune restriction ne lui sera appliquée.
Ces deux commandes sont très simple d’utilisation et peuvent rendre bien des services lorsque la bande passante est faible et que plusieurs utilisateurs se la partagent !
Ce n’est plus un secret, Windows 10 mise sur la compatibilité entre tous les types d’équipements afin d’avoir un système d’exploitation “universel”. Par contre, jusqu’à maintenant Microsoft fournit uniquement l’image d’installation de la version PC, mais quelques captures d’écrans de la version mobile sont apparues sur internet.
Les insiders bénéficient de la dernière version Technical Preview qui intègre les derniers changements ajoutés depuis la conférence de Microsoft. Bien que la version mobile ne soit pas disponible aux téléchargements, quelques privilégiés semblent l’avoir eue en main.
Il en résulte la mise en ligne de trois captures d’écrans de Windows 10 en mode mobile, cela permet de se donner une idée de l’interface qui nous attend. En espérant pouvoir tester cette version sur nos mobiles d’ici quelques semaines.
À première vue, même s’il ne s’agit qu’un aperçu des menus, le rendu semble agréable et en progrès par rapport à la version actuelle de Windows 8 Phone. Je vous laisse juger par vous-même.
Je tiens à préciser que ce contenu est toujours à prendre avec des pincettes, car nous ne sommes jamais sûrs qu’il s’agit d’images officielles.
.
