NordVPN

L’application native NordVPN est l’option recommandée pour se connecter aux serveurs NordVPN sur votre appareil Linux. En gardant à l’esprit votre expérience, nous avons conçu une application qui permet un accès facile aux fonctionnalités telles que CyberSec, la connexion automatique et le Kill Switch automatisé.

Ce tutoriel explique comment télécharger et installer l’application NordVPN, s’identifier et se connecter à nos serveurs. Vous pouvez également y trouver une explication de plusieurs paramètres.

1. Téléchargez le client NordVPN Linux depuis notre page de téléchargements ou cliquez sur ce lien direct.




Vous pouvez également utiliser cette commande et passer directement à l’étape 3 :

sudo wget -qnc https://repo.nordvpn.com/deb/nordvpn/debian/pool/main/nordvpn-release_1.0.0_all.deb

2. Ouvrez un terminal et exécutez la commande suivante :

sudo dpkg -i /pathToFile/nordvpn-release_1.0.0_all.deb

Veillez à remplacer /pathToFile/ par le chemin d’accès à votre dossier Téléchargements (ou tout autre emplacement où le fichier NordVPN a été téléchargé).

Exemple : sudo dpkg -i ~/Downloads/nordvpn-release_1.0.0_all.deb

Vous devrez saisir votre mot de passe racine. Saisissez-le, patientez pendant l’installation du package puis passez à l’étape suivante.

3. Mettez à jour la liste du package :

sudo apt update (ou sudo apt-get update)

4. Installez l’application NordVPN :

sudo apt install nordvpn (ou sudo apt-get install nordvpn)

5. Connectez-vous à votre compte NordVPN :

nordvpn login

6. Connectez-vous à un serveur NordVPN :

nordvpn connect



Si vous rencontrez l’erreur GPG (NO_PUBKEY), utilisez la commande suivante et répétez l’étape 4 :

sudo wget https://repo.nordvpn.com/gpg/nordvpn_public.asc -O - | sudo apt-key add -


Paramètres

Pour accéder aux paramètres du client NordVPN, saisissez la commande nordvpn dans un terminal.

Voici une liste des commandes disponibles :

nordvpn login - S’identifier.
nordvpn connect ou nordvpn c - Se connecter au VPN. Pour se connecter à des serveurs spécifiques, utilisez nordvpn connect (par exemple : nordvpn connect uk715)
nordvpn disconnect ou nordvpn d - Se déconnecter du VPN.

nordvpn set ou nordvpn s - Définir une option de configuration. Options possibles :
nordvpn set cybersec on ou off - Activer ou désactiver CyberSec.
nordvpn set killswitch on ou off - Activer ou désactiver le Kill Switch.
nordvpn set autoconnect on ou off - Activer ou désactiver la connexion automatique. Vous pouvez définir un serveur spécifique pour une connexion automatique à l’aide de la commande nordvpn set autoconnect on code_de_pays+numéro_de_serveur.

Exemple : nordvpn set autoconnect on us2435.

nordvpn set dns 1.1.1.1 1.0.0.1 - Définir un serveur DNS personnalisé (vous pouvez définir un DNS simple ou deux DNS, telle que l’indique cette commande).
nordvpn set protocol udp ou tcp - Alterner entre les protocoles UDP et TCP.
nordvpn set obfuscate on ou off - Activer ou désactiver les serveurs obfusqués.

nordvpn whitelist add port 22 - Ouvrir le port entrant 22 (le numéro de port peut être différent). Vous pouvez mettre en liste blanche plusieurs ports - il suffit de les séparer avec un espace.
nordvpn whitelist remove port 22 - Supprimer la règle ajoutée avec la commande ci-dessus.
nordvpn whitelist add subnet 192.168.0.0/16 - Ajouter une règle pour mettre les sous-réseaux spécifiés sur liste blanche.
nordvpn whitelist remove subnet 192.168.0.0/16 - Supprimez la règle de mise des sous-réseaux spécifiés sur liste blanche.

nordvpn settings - Afficher les paramètres actuels.
nordvpn status - Afficher le statut de connexion.
nordvpn countries - Afficher la liste de pays.
nordvpn cities - Afficher la liste de villes.
nordvpn groups - Afficher une liste de groupes de serveurs disponibles.
nordvpn logout - Se déconnecter.
nordvpn help ou nordvpn h - Afficher la liste des commandes ou l’aide pour une commande.

Pour consulter la liste complète des commandes, utilisez la commande man nordvpn dans un terminal.

https://books.google.be/books?id=felDAQAAQBAJ&lpg=PP1&hl=fr&pg=PP1&output=embed

https://www.tech2tech.fr

🌐 Mon blog : https://www.tech2tech.fr ----------------------------------------­­------------------------------ Il y a encore quelques mois, je vous ai expliqué comment installer macOS Mojave sur VirtualBox. Et bien aujourd'hui nous allons voir ensemble comment installer la toute dernière version de macOS Catalina sur votre PC avec Virtualbox. Attention, c'est un peu sport, mais si vous suivez le tuto ou la vidéo, ça se passera bien :) Si vous souhaitez plutôt utiliser VMware, c'est possible. N'hésitez pas à regarder le tutoriel pour VMware ici : https://www.youtube.com/watch?v=1JTNn... ----------------------------------------­­------------------------------
 📌Liens utiles liés à la vidéo : Télécharger VMware Player 
► http://bit.ly/VMPlayer15 Télécharger le pack de virtualisation Catalina via Torrent (ISO Catalina, VMware Unlocker...) 
► http://bit.ly/macOSCatalinaVBoxTorrent Télécharger le pack de virtualisation Catalina via Google Drive (ISO Catalina, VMware Unlocker...) 
► http://bit.ly/macOSCatalinaVboxGDrive 
Activer la virtualisation sur votre carte mère 
► https://www.tech2tech.fr/comment-acti... 
►Mon article sur le blog : https://www.tech2tech.fr/?p=84980

 📌MON MATERIEL DE TECHOS 

 📌MES LOGICIELS 
💾Camtasia pour la capture d'écran :
 http://bit.ly/CamtasiaTech 
💾FinalCut Pro pour le montage :
 https://www.apple.com/fr/final-cut-pro/

Cobalt

A propos de: Cobalt.

Cobalt est un conteneur d'application léger (c'est-à-dire un runtime d'application, comme une machine virtuelle Java ou Flash Player) qui est compatible avec un sous-ensemble des spécifications HTML5 du W3C. Si vous créez une application Web (SPA) d'une seule page conforme au sous-ensemble Cobalt des normes W3C, elle s'exécutera aussi bien que possible sur tous les appareils pris en charge par Cobalt.

Genèse, Origine, Évolutions, Besoins et Motivation !

Les auteurs Cobalt maintenaient à l'origine un portage de Chromium appelé H5VCC, le conteneur vidéo HTML5 pour consoles, porté sur chacune des principales consoles de jeu, conçu pour exécuter notre application de navigation et de lecture vidéo basée sur HTML5. Cela a pris beaucoup de temps à porter sur chaque plate-forme, composé de 9 millions de lignes de code C ++ (avant de le toucher), était dangereux à modifier sans conséquences imprévues et a été soigneusement conçu pour un environnement multi-processus riche en ressources (par exemple un ordinateur de bureau, un ordinateur portable ou un smartphone moderne).
Après avoir lutté avec cela pendant plusieurs années, nous avons imaginé un environnement qui n'était pas conçu pour le contenu Web de défilement traditionnel, mais qui devait être un environnement d'exécution pour des applications clientes riches construites avec les mêmes technologies - HTML, CSS, JavaScript - et conçues à partir de zéro pour fonctionner sur des appareils électroniques grand public (CE) contraints et intégrés, tels que des consoles de jeu, des décodeurs (par exemple, câble, satellite), des appareils OTT (par exemple, Roku, Apple TV, Chromecast, Fire TV ), Lecteurs de disques Blu-ray et téléviseurs intelligents.
Ces contraintes (qui ne sont pas censées être une liste canonique) rendent ce spectre d'appareils très différent de l'environnement informatique de bureau ciblé par Chromium, FireFox et IE:

• Mémoire limitée. Tous, à l'exception des tout derniers appareils CE coûteux, ont une très petite quantité de mémoire disponible pour les applications. Cela se situe généralement entre 200 et 500 Mo, y compris les graphiques et la mémoire multimédia, par opposition à plusieurs gigaoctets de mémoire CPU (et plus de gigaoctets de mémoire GPU) dans les ordinateurs de bureau et portables modernes et les appareils mobiles.
• CPU lents. La plupart des appareils CE ont des processeurs beaucoup plus lents que ceux disponibles sur un ordinateur de bureau économique. Des problèmes de performance mineurs peuvent être considérablement exagérés, ce qui affecte sérieusement les priorités.
• Moins de cœurs. Les processeurs CE System-on-a-Chip (SoC) n'ont souvent pas autant de cœurs de processeur que nous en avons l'habitude dans les ordinateurs modernes. De nombreux appareils déployés n'ont toujours qu'un seul cœur.
• Parfois, pas de GPU. Tous les appareils CE n'ont pas de GPU monstre pour lancer des shaders pour décharger le travail du processeur. Une stratégie différente est requise pour maximiser l'effet de levier d'un blitter accéléré, ce que possèdent tous les appareils plus anciens. Certains appareils CE plus récents ont un GPU, mais il n'est pas aussi puissant que ce que l'on verrait même sur un ordinateur portable.
• Parfois pas de JIT. De nombreux appareils CE traitent du «contenu de haute valeur» et, en tant que tels, sont très sensibles aux problèmes de sécurité. S'assurer que les pages inscriptibles ne sont pas exécutables est un protocole de sécurité puissant qui peut empêcher un large éventail d'attaques. Mais, comme effet secondaire, cela signifie également aucune capacité à JIT.
• Environnements de développement hétérogènes. C'est lentement le soir, mais tous les appareils CE fonctionnent sur du matériel personnalisé, souvent avec des méthodes propriétaires de construction, d'empaquetage, de déploiement et d'exécution de programmes. Presque tous les appareils CE ont des processeurs ARM ou MIPS au lieu du x86 plus familier. Parfois, la chaîne d'outils ne prend pas en charge les fonctionnalités C ++ 11 contemporaines. Parfois, le système d'exploitation n'est pas POSIX, ou il essaie de l'être, mais il n'est implémenté que partiellement. Parfois, le point d'entrée du programme est dans une autre langue ou architecture qui nécessite un «trampoline» sur du code binaire natif.
• Pas de navigation. Le point d'une application monopage est que vous ne passez pas par la danse de page HTTP chaque fois que vous changez d'écran. C'est lent et fournit une mauvaise rétroaction des utilisateurs, sans parler d'une transition discordante. Au lieu de cela, on charge des données à partir d'un XMLHttpRequest (XHR), puis met à jour son DOM pour refléter les nouvelles données. AJAX! Web 2.0!!
• Pas de défilement. Eh bien, les applications UI SPA de 10 pieds en plein écran peuvent défiler, mais pas comme les pages Web traditionnelles, avec des barres de défilement et une molette de la souris. Le défilement est généralement intégré à l'application très soigneusement, avec la prise en charge d'un pavé directionnel et d'un curseur de mise au point.

Architecture

Les auteurs Cobalt ont créé H5VCC, supprimé la plupart du code Chromium - en particulier WebCore et Chrome Renderer and Compositor - et construit à partir de zéro une implémentation d'un sous-ensemble simplifié de HTML, du modèle CSS Box pour la mise en page et des API Web qui étaient vraiment nécessaires pour construire une application de navigation et de lecture SPA en plein écran.
La pile technologique Cobalt comprend ces composants principaux, à peu près dans une application de haut niveau à un ordre de plate-forme de bas niveau:

• Implémentation Web - C'est là que les normes W3C sont implémentées, produisant finalement une arborescence DOM annotée qui peut être transmise au moteur de disposition pour produire une arborescence de rendu.
• JavaScript Engine - Nous avons, peut - être surprenant, pas écrit notre propre moteur JavaScript à partir de zéro. En raison de la contrainte JITing, nous devons être flexibles avec le ou les moteurs avec lesquels nous travaillons. Nous avons une couche de liaisons qui s'interface avec le moteur JS afin que le script d'application puisse s'interfacer avec des objets nativement soutenus (comme les éléments DOM).
• Moteur de mise en page - Le moteur de mise en page prend un document DOM annoté produit par l'implémentation Web et le moteur JavaScript en travaillant ensemble, et calcule une arborescence de commandes de rendu à envoyer au moteur de rendu (c'est-à-dire une arborescence de rendu). Il met en cache les artefacts de disposition intermédiaires afin que les dispositions incrémentielles suivantes puissent être accélérées.
• Renderer / Skia - Le Renderer parcourt un arbre de rendu produit par le moteur de mise en page, le pixellise à l'aide de la bibliothèque graphique tierce Skia, et l'échange vers le tampon avant. Il y a deux chemins principaux ici, l'un utilisant Hardware Skia sur OpenGL ES 2.0, et l'autre utilisant Software Skia combiné avec le Starboard Blitter à accélération matérielle. Notez que le rendu s'exécute dans un thread différent du moteur de mise en page et peut interpoler des animations qui ne nécessitent pas de nouvelle mise en page. Cela dissocie le rendu de Layout et JavaScript, permettant des animations fluides et cohérentes sur des plates-formes avec une variété de capacités.
• Net / Media - Ce sont les moteurs réseau et média de Chromium. Nous les utilisons directement, car ils ne posent aucun problème particulier avec les contraintes supplémentaires répertoriées ci-dessus.
• Base - Il s'agit de la bibliothèque «Base» de Chromium, qui contient une grande variété de choses utiles utilisées dans Cobalt, Net et Media. Cobalt utilise une combinaison de conteneurs C ++ standard (par exemple, vecteur, chaîne) et Base comme bibliothèque de base pour tout son code.
• Autres bibliothèques tierces - La plupart d'entre elles sont des bibliothèques open source vénérables, en C droit, qui sont généralement incluses dans d'autres logiciels open source. Formater principalement les décodeurs et les analyseurs (par exemple libpng, libxml2, zlib). Nous les dérivons de Chromium, car nous voulons qu'elles soient les versions les plus testées au combat de ces bibliothèques.
• Starboard / Glimp / ANGLE - Starboard est l'interface de portage Cobalt. Une différence majeure entre Cobalt et Chromium est que nous avons créé une couche de portage directe en C droit et porté TOUT le code compilé, y compris Base et toutes les bibliothèques tierces, pour l'utiliser au lieu d'utiliser directement les bibliothèques standard POSIX, qui sont pas cohérent, même sur les systèmes modernes (voir Android, Windows, MacOS X et iOS). De plus, Starboard inclut des API qui n'ont pas été efficacement standardisées sur toutes les plates-formes, telles que la création de fenêtres d'affichage, les événements d'entrée et la lecture de médias. Glimp est un framework d'implémentation OpenGL ES 2.0, construit par l'équipe Cobalt directement sur Starboard, conçu pour adapter les API 3D propriétaires à GLES2. ANGLE Est une bibliothèque tierce qui adapte DirectX à GLES2, similaire à Glimp, mais uniquement pour DirectX.

Le cobalt est comme une pâtisserie feuilletée en couches - peut-être le Baklava. Il ne devrait pas être trop difficile d'extraire l'implémentation et la mise en page Web du haut et d'utiliser simplement le rendu, ou même d'utiliser simplement Base + Starboard + GLES2 comme base d'un nouveau projet.

Le sous-ensemble de cobalt

Oh, nous avons les deux types de balises HTML,
nous avons et

!

Voir la spécification du sous-ensemble Cobalt pour plus de détails sur les balises, les propriétés et les API Web prises en charge dans Cobalt.
Plus à venir.

Emplacements sources intéressants

Tous les emplacements source sont spécifiés par rapport à src/(ce répertoire).

• base/- Bibliothèque de base de Chromium. Contient des utilitaires communs et une abstraction de plate-forme légère, qui a été remplacée dans Cobalt par Starboard.
• net/- Bibliothèque réseau de Chromium. Contient suffisamment d'infrastructure pour prendre en charge les besoins réseau d'un agent utilisateur HTTP (comme Chromium ou Cobalt), un serveur HTTP, un serveur DIAL et plusieurs abstractions pour les primitives de mise en réseau. Contient également les implémentations SPDY et QUIC.
• media/- Médiathèque de Chromium. Contient tout le code qui analyse, traite et gère les tampons de données vidéo et audio. Le décodage multimédia est transmis au matériel de décodage, dans la mesure du possible.
• cobalt/- La maison de tout le code d'application Cobalt. Cela inclut l'implémentation Web, le moteur de mise en page, le moteur de rendu et d'autres fonctionnalités spécifiques à Cobalt.
  • cobalt/build/- Le système de génération de build de base gyp_cobaltet les configurations pour les plateformes prises en charge. (REMARQUE: cela devrait finalement être principalement déplacé vers starboard/.)
• starboard/- Couche de portage de Cobalt. Veuillez consulter Starboard README.mdpour plus d'informations sur le portage de Starboard (et Cobalt) vers une nouvelle plate-forme.
• third_party/- Où vivent toutes les dépendances tierces de Cobalt. Nous ne voulons pas être perjoratifs, nous aimons nos bibliothèques tierces! Cet emplacement est dicté par les règles de gestion des versions de Google OSS ...
  • third_party/starboard/- L'emplacement des ports tiers. Ce répertoire sera analysé automatiquement par gyp_cobalt pour les ports Starboard disponibles.

Création et exécution du code

Voici un guide rapide et sale pour construire le code sous Linux.

1. Tirez depot_toolsdans votre répertoire préféré. Il a été légèrement modifié par rapport à celui de Chrome depot_tools.
   

   git clone https://cobalt.googlesource.com/depot_tools
   

2. Ajoutez ce répertoire à la fin de votre $PATH.
3. Assurez-vous que ces packages sont installés:
   

   sudo apt-get install libgles2-mesa-dev libpulse-dev libavformat-dev \
   libavresample-dev libasound2-dev libxrender-dev libxcomposite-dev
   

4. Assurez-vous que les fichiers d'en-tête C ++ standard sont installés (par exemple libstdc++-4.8-dev).
5. Pour l'instant, nous avons également besoin de rubis:
   

   sudo apt-get installer ruby
   

6. Retirez le bison-3 et installez le bison-2.7. (REMARQUE: nous prévoyons de passer au bison-3 à l'avenir.)
   

   $ sudo apt-get supprimer le bison
   $ sudo apt-get install m4
   $ wget http://ftp.gnu.org/gnu/bison/bison-2.7.1.tar.gz
   $ tar zxf bison-2.7.1.tar.gz
   $ cd bison-2.7.1
   $ sh configure && make && sudo make install
   $ quel bison
   / usr / local / bin / bison
   $ bison --version
   bison (GNU Bison) 2.7.12-4996
   

7. (À partir de ce répertoire) exécutez GYP:
   

   cobalt / build / gyp_cobalt -C debug linux-x64x11
   

8. Si vous obtenez une erreur «clang not found», ajoutez le chemin d'accès au clang de Cobalt à votre $PATHet réexécutez gyp_cobaltcomme ci-dessus. Par exemple:/path/to/cobalt/src/third_party/llvm-build/Release+Asserts/bin
9. Exécutez Ninja:
   

   ninja -C out / linux-x64x11_debug cobalt
   

10. Exécutez Cobalt:
    out / linux-x64x11_debug / cobalt [--url =]
    
    • Si vous souhaitez utiliser à la httpplace de https, vous devez transmettre l' --allow_httpindicateur à la ligne de commande Cobalt.
    • Si vous souhaitez vous connecter à un httpshôte qui n'a pas de certificat validable par notre ensemble d'autorités de certification racine, vous devez passer l' --ignore_certificate_errorsindicateur à la ligne de commande Cobalt.
    • Voir cobalt/browser/switches.ccpour plus d'options de ligne de commande.

Types de build

Cobalt a quatre niveaux d'optimisation de construction, allant du plus lent, le moins optimisé, avec le plus d'informations de débogage en haut (débogage) au plus rapide, le plus optimisé et avec le moins d'informations de débogage en bas (or):

Type	Optimisations	Enregistrement	Asserts	Les informations de débogage	Console
déboguer	Aucun	Plein	Plein	Plein	Activée
développer	Plein	Plein	Plein	Plein	Activée
qa	Plein	Limité	Aucun	Aucun	Activée
or	Plein	Aucun	Aucun	Aucun	désactivé

Lors de la construction pour la sortie, vous devez toujours utiliser une construction en or pour le produit final.

$ cobalt / build / gyp_cobalt -C or linux-x64x11
$ ninja -C out / linux-x64x11_gold cobalt
$ out / linux-x64x11_gold / cobalt

Origine de ce référentiel

Il s'agit d'une fourchette du référentiel de chrome sur http://git.chromium.org/git/chromium.git

Tribord

Starboard est la couche de portage et l'abstraction du système d'exploitation de Cobalt. Il tente d'englober toutes les fonctionnalités spécifiques à la plate-forme que Cobalt utilise réellement, et rien de ce qu'il ne fait pas.

Avis de migration GN

Cobalt et Starboard migrent actuellement du système de construction GYP vers le système de construction GN. Ce fichier Lisez-moi contient des instructions pour les deux systèmes. Pour l'instant, GN n'est pas prêt pour une utilisation générale pour Cobalt / Starboard. Si vous n'êtes pas un développeur Cobalt principal, vous devriez probablement ignorer les sections intitulées «Instructions GN» pour l'instant.

Documentation

Voir src/starboard/docpour une documentation plus détaillée.

Emplacements sources intéressants

Tous les emplacements source sont spécifiés par rapport à src/starboard/(ce répertoire).

• . - Il s'agit du répertoire racine du projet Starboard et contient tous les en-têtes publics définis par Starboard.
• examples/ - Exemple de code illustrant divers aspects de l'utilisation de l'API Starboard.
• stub/- La maison de la mise en œuvre Stub Starboard. Celui-ci contient un starboard_platform.gypfichier qui définit une bibliothèque avec tous les fichiers source nécessaires pour fournir une implémentation Starboard complète pouvant être liée.
• nplb/ - «No Platform Left Behind», suite de tests de vérification de plate-forme de Starboard.
• shared/- La maison de tout le code qui peut être partagé entre les implémentations de Starboard. Les sous-répertoires délimitent le code qui peut être partagé entre les plates-formes qui partagent une facette de leur API de système d'exploitation.

Guide rapide pour démarrer un port

I. Énumérer et nommer vos configurations de plate-forme

Avant de démarrer un port Cobalt / Starboard, vous devez d'abord définir les noms canoniques de votre ensemble de configurations de plate-forme. Ceux-ci seront utilisés lors de l'organisation du code pour vos plateformes.
Qu'est-ce qui détermine ce qui entre dans une configuration de plateforme par rapport à une autre? Une configuration de plate-forme a un mappage un à un avec un binaire de production. Donc, si vous devez produire un nouveau binaire, vous aurez besoin d'une nouvelle configuration de plate-forme pour cela.
La convention de dénomination recommandée pour a est:

 - 

Où est un nom spécifique à la famille de produits que vous portez sur Starboard et est un ou plusieurs jetons qui décrivent de manière unique les spécificités du binaire que vous souhaitez que cette configuration produise.
Par exemple, supposons que votre entreprise s'appelle BobCo. BobCo utilise plusieurs architectures de périphériques différentes, il devra donc définir plusieurs configurations de plate-forme.
Tous les appareils BobCo sont appelés BobBox, c'est donc un choix raisonnable en tant que produit . Mais ils ont des puces MIPS à la fois grandes et petites. Ils pourraient donc définir deux configurations de plate-forme:

1. bobbox-mipseb - Pour les appareils MIPS big-endian.
2. bobbox-mipsel - Pour les appareils MIPS peu endiens.

II. Choisissez un emplacement dans l'arborescence source pour votre port tribord

Pour être parfaitement compatible avec la disposition de l'arborescence des sources de Cobalt, tout code écrit par une partie qui n'est pas l'équipe de Cobalt doit se trouver dans le src/third_party/répertoire. Le choix vous appartient, mais nous vous recommandons de suivre cette pratique, même si, comme nous nous attendons à le faire, vous ne prévoyez pas de partager votre implémentation Starboard avec quelqu'un.
Principalement, le respect de cette convention garantit qu'aucune modification future de Cobalt ou Starboard n'entrera en conflit avec vos ajouts de code source. Starboard est destiné à être une jonction où les nouvelles versions de Cobalt ou les implémentations de Starboard peuvent être remplacées sans changements de code importants (et, espérons-le, tout).
Nous vous recommandons de placer votre code ici dans l'arborescence source:

src / tierce_partie / tribord /  /

Avec des sous-répertoires:

• shared/ - Pour le code partagé entre architectures au sein d'une famille de produits.
• /- Pour tout code spécifique à une variante binaire spécifique. Chacun d' entre eux doit au moins avoir configuration_public.h, atomic_public.h, thread_types_public.h, gyp_configuration.py, gyp_configuration.gypiet les starboard_platform.gypfichiers.

Dans l'exemple BobBox de BobCo, nous verrions quelque chose comme:

• src/third_party/starboard/bobbox/
  • shared/
  • mipseb/
    • atomic_public.h
    • configuration_public.h
    • gyp_configuration.gypi
    • gyp_configuration.py
    • starboard_platform.gyp
    • thread_types_public.h
  • mipsel/
    • atomic_public.h
    • configuration_public.h
    • gyp_configuration.gypi
    • gyp_configuration.py
    • starboard_platform.gyp
    • thread_types_public.h

Etc.

Instructions GN

Chaque /répertoire doit avoir au moins configuration_public.h, atomic_public.h, thread_types_public.h, BUILD.gn, configuration.gniet buildconfig.gni.
Dans l'exemple BobBox de BobCo, nous verrions une arborescence de répertoires comme:

• src/third_party/starboard/bobbox/
  • shared/
  • mipseb/
    • buildconfig.gni
    • configuration.gni
    • atomic_public.h
    • BUILD.gn
    • configuration_public.h
    • thread_types_public.h
  • mipsel/
    • buildconfig.gni
    • configuration.gni
    • atomic_public.h
    • BUILD.gn
    • configuration_public.h
    • thread_types_public.h

III. Basez votre port sur un port de référence

Vous pouvez commencer par copier des fichiers d'un port de référence vers l'emplacement de votre port. Actuellement, ces ports de référence incluent:

• src/starboard/stub
• src/starboard/linux
• src/starboard/raspi

Le starboard_platform.gypcontient des chemins absolus, donc les chemins seront toujours valides si vous le copiez dans un nouveau répertoire. Vous pouvez ensuite remplacer progressivement les fichiers par de nouvelles implémentations si nécessaire.
Le point de départ le plus propre et le plus simple provient de l'implémentation de référence Stub. Rien ne fonctionnera, mais vous devriez pouvoir le compiler et le lier à votre chaîne d'outils. Vous pouvez ensuite remplacer les implémentations de stub par des implémentations de src/starboard/sharedou vos propres implémentations personnalisées module par module, jusqu'à ce que vous ayez parcouru tous les modules.
Vous pouvez également choisir de copier les ports Desktop Linux ou Raspberry Pi et de travailler en arrière en réparant les choses qui ne compilent pas ou ne fonctionnent pas sur votre plate-forme.
Par exemple, pour bobbox-mipsel, vous pouvez faire:

mkdir -p src / third_party / tribord / bobbox
cp -R src / tribord / stub src / third_party / tribord / bobbox / mipsel

Modifiez les fichiers /comme il convient (vous reviendrez probablement beaucoup à ces fichiers).
Mettez /starboard_platform.gypà jour pour pointer vers tous les fichiers source que vous souhaitez créer en tant que nouvelle implémentation Starboard. L' '<(DEPTH)'expression dans GYP se développe en suffisamment de ../s pour vous emmener dans le src/répertoire de votre arborescence source. Sinon, les fichiers sont supposés être relatifs au répertoire dans lequel se trouve le fichier .gypou .gypi.
Pour utiliser une nouvelle configuration de la plate - forme dans une version, vous devez vous assurer que vous avez gyp_configuration.py, gyp_configuration.gypiet starboard_platform.gypdans leur propre répertoire pour chaque variante binaire, ainsi que les fichiers d' en- tête configuration_public.h, atomic_public.het thread_types_public.h. gyp_cobaltva analyser vos répertoires pour ces fichiers, puis calculer un nom de port en fonction des répertoires entre src/third_party/starboardet vos gyp_configuration.*fichiers. (Par exemple, pour src/third_party/starboard/bobbox/mipseb/gyp_configuration.py, il choisirait le nom de configuration de la plate-forme bobbox-mipseb.)

Instructions GN

Mettez /BUILD.gnà jour pour pointer vers tous les fichiers source que vous souhaitez créer en tant que nouvelle implémentation Starboard. L' //expression dans GN fait référence au src/répertoire de votre arborescence source. Sinon, les fichiers sont supposés être relatifs au répertoire dans lequel se trouve le fichier BUILD.gnou .gni. Le BUILD.gnfichier contient des chemins absolus, donc les chemins seront toujours valides si vous le copiez dans un nouveau répertoire. Vous pouvez ensuite remplacer progressivement les fichiers par de nouvelles implémentations si nécessaire.
Pour utiliser une nouvelle configuration de la plate - forme dans une version, vous devez vous assurer que vous avez BUILD.gn, configuration.gniet buildconfig.gnidans leur propre répertoire pour chaque variante binaire, ainsi que les fichiers d' en- tête configuration_public.h, atomic_public.het thread_types_public.h. La version GN va scanner vos répertoires pour ces fichiers, puis calculer un nom de port basé sur les répertoires entre src/third_party/starboardet vos configuration.gnifichiers. (par exemple pour src/third_party/starboard/bobbox/mipseb/configuration.gni, il choisirait le nom de configuration de la plate-forme bobbox-mipseb.)

IV. Un nouveau port, étape par étape

1. Copiez récursivement src/starboard/stubvers src/third_party/starboard//. Vous pouvez également envisager de copier à partir d'une autre plate-forme de référence, comme raspi-2ou linux-x64x11.
2. Dans gyp_configuration.py
   1. Dans la CreatePlatformConfig()fonction, passez votre comme paramètre au constructeur PlatformConfig, comme return PlatformConfig('bobbox-mipseb').
   2. Dans GetVariables
      1. Définissez 'clang': 1si votre chaîne d'outils est bruyante.
      2. Supprimez les autres variables de cette fonction qui ne sont pas nécessaires pour votre plate-forme.
   3. Dans GetEnvironmentVariables, définissez les valeurs du dictionnaire pour pointer vers les analogues de la chaîne d'outils pour la chaîne d'outils de votre plate-forme.
3. Dans gyp_configuration.gypi
   1. Mettre à jour les noms des configurations et le default_configuration être _pour votre nom de la configuration de la plate - forme, où est l' une debug, devel, qa, gold.
   2. Mettez à jour vos variables de plateforme.
      1. Réglez 'target_arch'à votre architecture: 'arm', 'ppc', 'x64', 'x86','mips'
      2. Définissez 'target_os': 'linux'si votre plateforme est basée sur Linux.
      3. Définissez 'gl_type': 'system_gles2'si vous utilisez l'implémentation du système EGL + GLES2.
      4. Réglez 'in_app_dial'sur 1ou 0. Cela active ou désactive le serveur DIAL qui s'exécute à l'intérieur de Cobalt, uniquement lorsque Coblat est en cours d'exécution. Vous ne voulez pas de DIAL intégré à l'application si vous disposez déjà d'un support DIAL à l'échelle du système.
   3. Mettez à jour vos indicateurs et bibliothèques de ligne de commande de la chaîne d'outils. Assurez-vous de ne pas assumer une disposition de poste de travail particulière, car elle sera probablement différente pour quelqu'un d'autre.
   4. Mettez à jour les définitions globales dans 'target_defaults'.'defines', si nécessaire.
4. Parcourez configuration_public.het ajustez toutes les valeurs de configuration en fonction de votre plate-forme.
5. Mettez starboard_platform.gypà jour pour pointer vers tous les fichiers source que vous souhaitez créer dans le cadre de votre nouvelle implémentation Starboard (comme mentionné ci-dessus).
6. Mettez à jour atomic_public.het, thread_types_public.hsi nécessaire, pour pointer vers les implémentations partagées ou personnalisées appropriées.

Vous devriez maintenant pouvoir exécuter gyp avec votre nouveau port. Depuis votre src/annuaire:

$ cobalt / build / gyp_cobalt -C debug bobbox-mipseb
$ ninja -C out / bobbox-mipseb_debug nplb

Cela tentera de créer la suite de tests «Aucune plate-forme laissée pour compte» avec votre nouvelle implémentation Starboard, et vous êtes prêt à commencer le portage!

Instructions GN

Suivez la liste ci-dessus, sauf:

1. Ignorez les étapes sur gyp_configuration.pyet gyp_configuration.gypi.
2. Mettre à jour BUILD.gnau lieu de starboard_platform.gyp.
3. Aussi dans BUILD.gn:
   1. Mettez à jour vos indicateurs et bibliothèques de ligne de commande de chaîne d'outils, pour toutes les configurations ainsi que pour chaque configuration individuelle.
   2. Implémentez des configurations de compilateur génériques telles que sb_pedantic_warningset rtti.
   3. Si vous n'utilisez pas une chaîne d'outils prédéfinie, définissez-en une.
4. Dans buildconfig.gni:
   1. Si votre plate-forme est basée sur Linux, définissez target_os_ = "linux".
   2. Réglez target_cpu_votre architecture cible (par exemple arm, ppc, x64, x86, mips).
   3. Définissez les chaînes d'outils cible et hôte. Si vous avez défini une chaîne d'outils cible dans BUILD.gn, vous voudrez la définir sur cela.
5. Dans configuration.gni, définissez les valeurs par défaut spécifiques à la plate-forme pour toutes les variables qui doivent être remplacées pour votre plate-forme Starboard. Vous pouvez trouver une liste de ces variables sur //cobalt/build/config/base.gniet //starboard/build/config/base.gni.

Vous devriez maintenant pouvoir exécuter GN avec votre nouveau port. Depuis votre src/annuaire:

$ gn args out / bobbox-mipseb_debug

Un éditeur s'ouvrira. Tapez dans l'éditeur:

cobalt_config = "debug"
target_platform = "bobbox-mipseb"

Enregistrez et fermez l'éditeur. Ensuite, exécutez

$ ninja -C out / bobbox-mipseb_debug nplb

Cela tentera de créer la suite de tests «Aucune plate-forme laissée pour compte» avec votre nouvelle implémentation Starboard, et vous êtes prêt à commencer le portage!

Ordonnance de mise en œuvre suggérée

Lorsque vous lancez une nouvelle plate-forme Starboard, il est suggéré d'essayer de faire passer les tests NPLB module par module. En raison des dépendances entre les modules, il vous sera plus facile de faire passer certains modules plus tôt que d'autres modules.
Voici un ordre d'implémentation du module recommandé dans lequel faire avancer les choses (toujours soumis à des changements importants en fonction des commentaires):

1. Configuration
2. main (), Application et Event Pump (c'est-à-dire l'appel dans SbEventHandle)
3. Mémoire
4. Échange d'octets
5. Temps
6. Chaîne / Caractère / Double
7. Journal
8. Fichier
9. Annuaire
10. Système
11. Atomique
12. Fil et types de fil
13. Mutex
14. Variable de condition
15. Une fois que
16. Prise
17. SocketWaiter
18. Fenêtre
19. Contribution
20. Blitter (le cas échéant)
21. Récepteur audio
22. Lecteur multimédia
23. DRM
24. Fuseau horaire
25. Utilisateur
26. Espace de rangement