Libérez le potentiel Cygwin

Magazine
Marque
Linux Pratique
Numéro
79
|
Mois de parution
septembre 2013
|
Domaines


Résumé
Vous êtes un virtuose de la ligne de commandes Linux et vous déprimez d'être contraint d'utiliser un Windows au bureau ? Vous pensez que vos traitements ne sont pas convenablement scriptables sur le système de Microsoft, ou souffrez d'une allergie au AltGr-Backslash ? C'est que vous ne connaissez pas encore Cygwin.

Body

1 Présentation

1.1 Rappel des faits

Débuté en 1984, le projet GNU s'attela pendant plusieurs années à réécrire sous licence libre les commandes du système UNIX, en vue de créer un OS alternatif qui en reprenne les bons concepts [GNU]. Le portage de la collection de commandes de manipulation de fichiers, de flux de texte, de communication en réseau etc., avança à grands pas, mais le projet coinçait sur le noyau. Or un OS sans noyau (gestion de la mémoire, du matériel, des processus, etc.), ce n'est pas un OS. Il a fallu attendre l'arrivée de Linux en 1992 pour boucler la boucle et obtenir un système GNU/Linux complet (moyennant quelques efforts tout de même) [LINUX].

D'autres options existent pour doter le système GNU d'un noyau, dont le célèbre FreeBSD, et une tentative maison nommée the Hurd [HURD], qui n'a jamais vraiment réussi à se stabiliser ni à convaincre. Néanmoins, les auteurs du projet GNU sont beaux joueurs et admettent que mieux vaut un efficace et libre GNU/Linux que rien du tout.

Pour autant, le projet Cygwin (initialement porté par la société Cygnus Solutions en 1989, rachetée par RedHat en 2000 [CYGN]) est parti du constat que les outils GNU présentent un intérêt en eux-mêmes, indépendamment du noyau, et méritent d'être utilisés sur les systèmes Windows. L'équipe, non dénuée d'humour [ACRO], débuta donc un travail de portage des outils GNU pour cette plate-forme. Aujourd'hui la presque totalité des shells et commandes en ligne disponibles sur Linux le sont aussi sur Cygwin, pour le plus grand bonheur des utilisateurs Windows.

1.2 Cyqui ?

Alors, comment ça marche ? Pour faire simple : Cygwin est une couche de bas niveau (en fait une DLL) contenant des fonctions qui simulent le comportement de ce que les programmes d’un système GNU/Linux trouvent au-dessous d’eux (l'interface POSIX [POSIX]). Cygwin s’accompagne donc d’un grand nombre de programmes issus du toolkit GNU, recompilés pour fonctionner avec la DLL Cygwin, plutôt que les appels système spécifiques à Windows et sa fameuse Kernel32.dll.

Il s’agit donc d’un programme Windows (appelons-le un sous-système), qui va vous permettre d’utiliser le shell Bash (ou autre) et toutes vos commandes préférées (find, sed, grep, wget, etc.) ainsi que les liens symboliques de fichiers.

2 Mise en œuvre

2.1 Installation

Le programme se télécharge sur le site du projet [INST], sur toutes les versions modernes de Windows. Vous installerez Cygwin dans un répertoire dédié, sans espaces dans le nom (typiquement C:\cygwin) et il sera une bonne idée de conserver le fichier setup.execar vous vous en resservirez pour modifier l’installation : ajouter et supprimer des outils, monter de version, télécharger les sources, etc. En effet, le sous-système Cygwin n’ayant que très peu à faire avec le Windows sous-jacent (du point de vue de l’utilisateur), vous ne le retrouverez pas dans la rubrique « Ajouter ou Supprimer un Programme » de votre Panneau de Contrôle Windows.

cygwin-setup

Fig. 1 : Écran de sélection des paquets

Après sélection d'un miroir de téléchargement (vous jugerez de la popularité du projet au nombre impressionnant de miroirs), le Setup vous laisse choisir (ou modifier, si vous le lancez ultérieurement) quels outils vous intéressent, classés par catégories. Tout s’installera dans le dossier racine que vous aurez choisi au préalable, sans aucune autre interaction avec les fichiers de Windows, ni le registre.

En particulier, pour totalement supprimer Cygwin de votre système, il vous suffira de supprimer le dossier qui le contient.

2.2 Premiers pas

2.2.1 Le Terminal

Si la seule chose que Cygwin apportait était le terminal, le projet vaudrait quand même encore le coup (euh). À tous les familiers de PuTTy sur Windows, le mintty de Cygwin vaut clairement le détour (pour les autres : PuTTy est un client de connexion à des sessions Telnet et SSH... lorsqu'on ne dispose pas d'un terminal décent avec la commande ssh « native » ! d'où Cygwin CQFD).

Il prend en charge le redimensionnement dynamique de la fenêtre, les boutons de la souris, la transparence, les touches de fonction. C'est un terminal multi-fenêtres très agréable qui n'a rien à envier à ceux livrés avec MacOS ou avec votre bureau GNU/Linux préféré.

Le terminal se lance au moyen du raccourci de bureau ou dans le menu Démarrer, et je conseille en outre d'y associer une combinaison de touches afin de l'avoir à portée de Ctrl-Alt- (quitte à sombrer dans la ligne de commandes, autant le faire pour de bon). C'est bien sûr par défaut le bash qui vous accueille lorsque vous ouvrez un terminal.

gabriel@looping ~

$ pwd

/home/gabriel

2.2.2 La croisée des chemins

Une des différences fondamentales entre les modèles Windows et POSIX, du point de vue de la ligne de commandes, se situe au niveau des chemins de fichiers. Pas de C:\ dans un Linux. Et le séparateur de dossier n'est pas la plus grosse divergence, songez plutôt : les points de montage, les liens symboliques, les permissions POSIX, les pseudo-dossiers (processus, devices) etc. Pire, le filesystem de Microsoft n'est pas sensible à la casse.

Pour réconcilier ces deux modèles, Cygwin s'auto-confine dans un répertoire racine / qui correspond « physiquement » à votre C:\cygwinet dans lequel se trouvent les conventionnels bin, etc, home, var, dev, tmp et ainsi de suite. Il y ajoute le répertoire virtuel /cygdrive dans lequel vous retrouverez tous vos volumes Windows lettrés, donc en particulier /cygdrive/c (notez la minuscule et sans les deux-points), qu'il s'agisse de volumes fixes ou amovibles, de disques durs ou optiques, et même de montages réseau réalisés par Windows.

À l'instar de Linux, à chaque user Windows qui lance le shell une première fois, correspond un répertoire (physique) sous /home (c'est-à-dire dans c:\cygwin\home). Quant à vos documents Windows, ils ont toutes les chances de se trouver quelque part vers /cygdrive/c/Users/gabriel/Documents. Aussi, vous pourrez voir un intérêt à créer un lien symbolique (ln -s) dans votre home vers vos documents Windows, et un raccourci Windows dans votre « My Documents » (ou sur votre Desktop) vers votre home (notez l'asymétrie).

Les packages que vous installez dans le setup Cygwin sont placés dans le /bin qui lui-même est par défaut dans votre variable d'environnement PATH (de Cygwin ! pas de Windows) et vous pouvez donc lancer sans attendre vos find et autres tail. Les programmes Cygwin qui manipulent des fichiers en argument s'attendent à des chemins POSIX. Mais vous pouvez tout aussi bien lancer depuis votre terminal des programmes Windows (notepad.exe hihi) : dans ce cas, vous devrez indiquer des chemins Windows, car aucune chance que Notepad ouvre pour vous le fichier /home/gabriel/fichier.txt.

Pourtant, vous pourrez avoir besoin de scripter, avec votre bash tout neuf, l'invocation de programmes Windows (il vous en reste bien quelques-uns d'utiles, autrement vous ne liriez pas cet article). Pour résoudre cette difficulté, Cygwin apporte l'outil cygpath qui permet la conversion (de chaînes) entre les deux formats de chemins.

gabriel@looping ~

$ cygpath -D

/cygdrive/c/Users/gabriel/Desktop

gabriel@looping ~

$ cd $(cygpath -D)

gabriel@looping /cygdrive/c/Users/gabriel/Desktop

$ cygpath "C:\windows"

/cygdrive/c/windows

3 Devenez balaise

Les raisons que l'on peut avoir de vouloir utiliser Cygwin dépassent bien sûr les ls et pwd. Vous allez vouloir révolutionner votre usage de l'automatisation dans Windows, et peut-être même réutiliser tels quels vos scripts préférés que vous faites tourner depuis longtemps sur Linux. Cela est possible pour les raisons exposées ci-dessous.

3.1 Cette chère tuyauterie

Cet article n'étant pas un cours sur POSIX ou Bash ou la ligne de commandes, je n'entrerai pas dans les détails. Notez simplement que le sous-système Cygwin permet la manipulation des pipes entre processus, la redirection des entrées/sorties standards, les commandes imbriquées et les tâches parallèles (^Z, bg, fg, &). Autant de concepts desquels les habitués ne peuvent se passer, et auxquels les nouveaux arrivants trouveront vite un usage incontournable.

3.2 Tel laid commande

(ou : ce que je m'installe dès que j'atterris dans un Windows)

Tout ce que l'on fait de son GNU/Linux n'est pas automatiquement transposable sur Cygwin, et inversement Windows fait certaines choses très bien (ou avec l'aide des bons programmes pour cette plate-forme) sans qu'il ne faille absolument vouloir imiter son voisin pingouin.

Après quelques années de manipulation acharnée, voici donc un petit bouquet (qui n'engage que moi) de ce que j'estime très utile dans mon quotidien (de développeur+bricoleur+sysadmin). J'en profite pour insister sur le fait que l'outil Cygwin en général, et les commandes et paquets ci-dessous en particulier, rendront la vie de certains administrateurs Windows (si vous nous lisez) infiniment plus facile et moins chère (pour leur patron) s'ils veulent bien se donner la peine de s'y pencher.

Là encore, l'ambition n'est pas de détailler ces outils et leur usage, mais simplement de proposer une composition généraliste et efficace pour une première installation de Cygwin que chacun personnalisera :

curl     find    gawk   gcc

git      grep    gzip   head

less     md5sum scp    sed

openssh svn     tail   tar

unzip    vim     watch wc

wget     zip

J'en oublie certainement, mais en général on s'en rend vite compte. Ça n'a l'air de rien, mais la question reste entière : comment fait un sysadmin Windows pour travailler correctement (sans Cygwin) ?

Certains diront que tout ceci n'est bon que pour des traitements finalement très linuxiens, mais que dans la pratique, on ne peut pas tout faire en ligne de commandes (si bonne soit-elle) sur Windows. Ce n'est pas faux, mais lisez le paragraphe suivant (mais, ce n'est pas faux et lisez le chapitre 4).

3.3 Les outils Windows

Cygwin apporte quelques outils supplémentaires propres à ce projet, qui permettent d'aller plus loin dans ce qu'il est possible de faire avec le système Windows en ligne de commandes, en particulier dans des scripts. Vous trouverez notamment : getfacl et setfacl pour manipuler les permissions Windows (Access Control List) sur les fichiers, ainsi que regtool, qui facilite la manipulation du registre Windows, comme son nom l'indique.

En outre, et bien que certaines tâches ne demeurent automatisables qu'au travers du Windows Script Host [WSH], vous retrouverez sûrement grâce à Cygwin une nouvelle vie pour certaines commandes natives Windows depuis longtemps oubliées car, il faut bien le dire, pas très utiles en dehors d'un shell décent (c'est-à-dire à dire offrant pipes, capture de sortie standard, etc.). C'est notamment le cas de la commande net qui permet bien des choses (manipulation des utilisateurs Windows, réinitialisation de mots de passe, partages du réseau, etc.).

Pour le reste, il faudra peut-être tout de même se tourner vers le Windows Script Host, mais cela sort du cadre de cet article.

3.4 Services

La plupart des applications serveur sont disponibles pour la plate-forme Windows, aussi il n'est généralement pas nécessaire de se tourner vers leur portage Cygwin spécifique. Notamment, si les packages Lighttpd et Apache Httpd existent pour Cygwin, vous préférerez probablement pour des raisons de performance leur version native (et lirez pourquoi ici [APA]).

3.4.1 SSH

Néanmoins, pour certains d'entre eux comme OpenSSHd essentiellement, c'est bien sûr en installant la version Cygwin que vous profiterez au maximum de ce que vous offre ce sous-système, pour vos connexions SSH distantes vers votre machine Windows. Pour exécuter sshd comme un service Windows, vous aurez besoin d'installer le package Cygwin cygrunsrv, qui réalise le pont entre daemon Linux et service NT.

Pour déployer votre serveur SSH, configurez tout d'abord l'hôte Windows de la façon suivante :

$ ssh-host-config

*** Info: Creating default /etc/ssh_config file

*** Info: Creating default /etc/sshd_config file

*** Info: Privilege separation is set to yes by default since OpenSSH 3.3.

*** Info: However, this requires a non-privileged account called 'sshd'.

*** Info: For more info on privilege separation read /usr/share/doc/openssh/README.privsep.

*** Query: Should privilege separation be used? (yes/no)

Répondez yes. La séparation de privilèges est la technique qui permet d'enfermer les éventuels défauts du programme sshd, afin qu'une sortie inopinée du processus dans les graviers ne laisse pas un shell root à l'attaquant par exemple [PRIV].

La séparation de privilèges nécessitera la création par l'assistant d'un compte Windows spécial (très « unprivileged »). À ce titre, il aura fallu que vous lanciez la commande ssh-host-config dans un compte Windows ayant la permission de créer des utilisateurs (généralement, il s'agit des membres du groupe Administrateurs) :

*** Info: Note that creating a new user requires that the current account have

*** Info: Administrator privileges. Should this script attempt to create a

*** Query: new local account 'sshd'? (yes/no)

Répondez yes (dire no vous ramènerait au mode sans séparation de privilèges).

*** Query: Do you want to install sshd as a service?

*** Query: (Say "no" if it is already installed as a service) (yes/no) yes

*** Query: Enter the value of CYGWIN for the daemon: []

yes : vous voudrez manifestement déployer un service Windows (c'est la raison pour laquelle nous faisons tout ceci) et vous pourrez laisser vide la valeur de la variable CYGWIN demandée : il s'agit d'options supplémentaires pour le contexte d'exécution du daemon, dont la plupart sont obsolètes et prises par défaut depuis plusieurs versions.

*** Info: On Windows Server 2003, Windows Vista, and above, the

*** Info: SYSTEM account cannot setuid to other users -- a capability

*** Info: sshd requires. You need to have or to create a privileged

*** Info: account. This script will help you do so.

*** Info: You appear to be running Windows XP 64bit, Windows 2003 Server,

*** Info: or later. On these systems, it's not possible to use the LocalSystem

*** Info: account for services that can change the user id without an

*** Info: explicit password (such as passwordless logins [e.g. public key

*** Info: authentication] via sshd).

*** Info: If you want to enable that functionality, it's required to create

*** Info: a new account with special privileges (unless a similar account

*** Info: already exists). This account is then used to run these special

*** Info: servers.

*** Info: Note that creating a new user requires that the current account

*** Info: have Administrator privileges itself.

*** Info: No privileged account could be found.

*** Info: This script plans to use 'cyg_server'.

*** Info: 'cyg_server' will only be used by registered services.

*** Query: Do you want to use a different name? (yes/no)

Ce message est intimement lié à la façon dont Cygwin fait coexister POSIX et Windows, en ce qui concerne l'authentification : il vous informe que la connexion SSH par mot de passe explicite sera toujours possible, mais que si vous souhaitez profiter des fonctionnalités de connexion par paire de clés publique/privée, il faudra pour cela que le processus Windows sache basculer automatiquement de compte utilisateur.

Ceci n'est pas possible pour le compte LocalSystem classiquement utilisé par Windows pour les services (tels que l'assistant de mise à jour Windows Update, ou autres). C'est pourquoi on vous demande la création d'(encore !) un compte Windows (cette fois-ci très « privileged »), qui sera celui sous lequel s'exécuteront vos services Cygwin ayant ce don de transformiste. En particulier, vous pourrez le réutiliser pour le Cron.

Répondez donc no cette fois (sauf si ce nom proposé cyg_server ne vous revient pas).

Si vous préférerez limiter l'usage de votre serveur SSH à votre propre compte uniquement, vous pouvez préciser ici votre nom d'utilisateur plutôt que d'en faire créer un autre par l'assistant. Il vous faudra alors saisir votre mot de passe, et vous ne pourrez jamais vous connecter en SSH sous un autre login.

Puis vous pourrez enfin lancer le service Windows désormais installé :

$ cygrunsrv -S sshd

Vous retrouverez le service sshd dans le panneau de configuration des Services Windows et pourrez également le contrôler indifféremment par net start / stop ou cygrunsrv -S / -E.

N'oubliez pas de configurer votre pare-feu pour permettre les connexions entrantes sur ce daemon, et vous bénéficierez désormais d'un moyen puissant de vous connecter en ligne de commandes sécurisée à votre Windows.

3.4.2 Cron

Cron est également un autre service très intéressant dans le contexte Windows + Cygwin, qui vous permettra de décupler (au moins) les capacités de planification de votre système. Après avoir téléchargé dans le Setup le package Cygwin éponyme, vous l'installerez en lançant :

$ cron-config

La documentation complète du Crontab est disponible sur le Web, et le portage Cygwin est parfait, inutile donc de détailler plus avant dans cet article.

3.5 Serveur X

Cygwin offre dans ses paquets un serveur X-Window par le portage de Xorg. Vous devrez installer les paquets xinit et xorg-server, puis vous pourrez démarrer un serveur X sur votre machine Windows de la façon suivante (une seule fenêtre Windows contenant un bureau X) :

$ startx &

Ou encore, pour démarrer le serveur X en mode multi-fenêtres sans fond :

$ startxwin &

Vous pourrez y rediriger l'affichage d'une application X quelconque (locale ou distante).

Cela peut s'avérer pratique si vous devez exécuter depuis votre Windows une application X distante, sans que vous n'ayez par ailleurs la possibilité d'établir une connexion FreeNX ou VNC ou autre. Mais les possibilités (et le look and feel) sont assez limitées, et ce n'est pas là l'usage principal que l'on fait en général de Cygwin. Notez néanmoins que certains projets [CYGP] s’attellent à porter les environnements Desktop KDE, GNOME et d'autres, pour Cygwin. Leur mise en œuvre est complexe et approximative, et mis à part pour se vanter devant les collègues, je ne vois pas là non plus un intérêt fulgurant en termes de gain en productivité quotidienne sur Windows – mieux vaudrait passer à de la machine virtuelle et du KDE sur Linux natif (sans bien sûr porter de jugement sur l'extrême intérêt que ce projet peut représenter pour ses contributeurs en termes de R&D !).

4 Ce que Cygwin n'est pas

Comme déjà dit plus haut, Cygwin n'est autre, en réalité, qu'une DLL Windows qui apporte des fonctions effectuant la traduction, autant que faire se peut, entre l'API POSIX et l'API native Win32. Pour fonctionner sous Cygwin, un programme doit être compilé spécialement pour cette cible, et lier la cygwin1.dll. Il demeure donc un certain nombre de choses que Cygwin ne permet pas de faire. En particulier :

- Cygwin ne permet pas d'exécuter des binaires Linux sur Windows ;

- ni de faire des montages de filesystem subtiles avec mount ;

- la présence de Cygwin sur un système Windows ne confère pas automatiquement à un programme Windows des compétences POSIX (signaux, pty, etc.). Les programmes doivent être écrits spécialement pour faire usage de ces fonctionnalités, et compilés/liés avec l'environnement Cygwin.

De plus, il existe certaines limites à l'interopérabilité des systèmes POSIX et Windows quant aux permissions sur les fichiers. En effet, dans le modèle Windows, un fichier porte une liste de permissions et interdictions pour un nombre arbitraire d'utilisateurs et de groupes. Le modèle POSIX ne définit que trois niveaux (propriétaire, groupe (un seul !), et tout le monde). Cygwin tâche de faire coexister ces deux conceptions, mais dans certaines situations, il n'est pas possible de conférer convenablement les permissions avec le seul chmod, et à l'inverse la modification de permissions via Windows peut entraîner (plus rarement) des difficultés à ouvrir les fichiers par Cygwin, d'où la nécessité du susmentionné setfacl.

Néanmoins, dans le cas général, cela reste tout à fait acceptable et ne pose que très rarement des difficultés, tout en permettant d'ouvrir d'infinis horizons.

Références

[ACRO] http://www.cygwin.com/acronyms/

[APA] http://httpd.apache.org/docs/1.3/cygwin.html#diff

[CYGN] http://en.wikipedia.org/wiki/Cygnus_Solutions

[CYGP] http://cygwinports.org

[GNU] http://www.gnu.org/

[HURD] http://en.wikipedia.org/wiki/GNU_Hurd

[INST] http://www.cygwin.com/install.html

[LINUX] http://www.gnu.org/gnu/linux-and-gnu.html

[POSIX] http://en.wikipedia.org/wiki/POSIX

[UTIL] http://www.cygwin.com/cygwin-ug-net/using-utils.html

[WSH] http://en.wikipedia.org/wiki/Windows_Script_Host


Sur le même sujet

Les alternatives à Git

Magazine
Marque
GNU/Linux Magazine
HS n°
Numéro
107
|
Mois de parution
mars 2020
|
Domaines
Résumé

Dans le petit monde des gestionnaires de versions concurrentes, il n'existe pas que Git. D'autres projets permettent également de conserver les différentes versions d'un code et cet article permettra d'en faire un petit tour d'horizon.

Git, un tour d’horizon

Magazine
Marque
GNU/Linux Magazine
HS n°
Numéro
107
|
Mois de parution
mars 2020
|
Domaines
Résumé

Le vocabulaire et les concepts-clés de Git ayant été définis dans le précédent article, nous allons maintenant nous intéresser à la manière dont les concepts présentés se réalisent à l’aide des commandes de l’outil. Bref, passons à la pratique !

Analyse UEFI avec Windbg

Magazine
Marque
MISC
Numéro
108
|
Mois de parution
mars 2020
|
Domaines
Résumé

La dernière étape dans la mise en place d’un environnement de travail complet en UEFI va être l’installation d’un debugger. Celui-ci va permettre de, non seulement faciliter le développement au sein du micrologiciel, mais aussi de comprendre dynamiquement le code source. Dès lors, il sera possible de mieux appréhender ce code afin de l’éditer et créer son propre UEFI.

Pipelines en folie avec GitLab

Magazine
Marque
GNU/Linux Magazine
HS n°
Numéro
107
|
Mois de parution
mars 2020
|
Domaines
Résumé

Il y a tout un tas d'expressions qui prêtent à réfléchir, comme : il n'y a rien de mieux que de ne rien faire, ou il n'y a que ceux qui ne font rien qui ne se trompent pas. C'est plus ou moins ce qui est mis en application dans une chaîne de CI/CD : au moindre commit, une foule de petits robots se mettent en branle pour faire tout le nécessaire au déploiement de nos applications. Et si nous nous penchions sur toute cette machinerie ?

Préparer un système GNU/Linux temps réel pour vos applications audio

Magazine
Marque
Linux Pratique
Numéro
118
|
Mois de parution
mars 2020
|
Domaines
Résumé

Pendant longtemps, je me suis amusé à compiler des noyaux Linux afin de paramétrer mes ordinateurs avec les options correspondantes au matériel les composant. Par la suite, j’ai découvert la possibilité d’optimiser encore plus le cœur de mes systèmes GNU/Linux avec les fonctionnalités dites « temps réel », notamment pour faire tourner des logiciels audio avec le serveur de son Jack.

Par le même auteur

Automatiser les tests end-to-end en PHP

Magazine
Marque
GNU/Linux Magazine
Numéro
232
|
Mois de parution
décembre 2019
|
Domaines
Résumé

La partie frontale d'une application orientée utilisateur est généralement perçue comme difficile à tester de manière automatisée, et ces vérifications sont souvent reléguées à une campagne manuelle. Dans cet article, nous verrons comment utiliser l'outil Puppeteer dans un projet PHP, afin de garantir la validation déterministe de la partie d'une application web qui se joue dans le navigateur.

Automatiser la production de PDF avec Chromium

Magazine
Marque
GNU/Linux Magazine
Numéro
228
|
Mois de parution
juillet 2019
|
Domaines
Résumé
La conversion de documents HTML en fichiers PDF peut s’obtenir de différentes manières, chacune avec ses limites que ce soit dans l'automatisation, la souplesse ou la fidélité. Nous étudierons ici une solution mettant en œuvre Chromium pour un rendu professionnel et riche en fonctionnalités.

Plongée dans l'OPcache

Magazine
Marque
GNU/Linux Magazine
Numéro
224
|
Mois de parution
mars 2019
|
Domaines
Résumé

Depuis le début de sa carrière comme simple outil de traitement de formulaires HTML, le PHP a considérablement évolué pour devenir un langage mûr et abouti. Mais, contrairement à d'autres, il n'a pas été conçu au départ pour prendre en charge la distribution de code compilé. Étudions ceci de plus près.

L'auto-hébergement léger de dépôts git avec Gitolite

Magazine
Marque
GNU/Linux Magazine
Numéro
214
|
Mois de parution
avril 2018
|
Domaines
Résumé
Vous souhaitez mettre en place un serveur de dépôts Git privé pour vos projets personnels ou d'équipe, mais vous ne voulez pas d'une offre payante ni d'une usine à gaz, ni d'un service hébergé chez un tiers. Des solutions existent, et parmi elles l'outil Gitolite : simple, sûr, efficace et non captif.

Démystifier l’injection de dépendances en PHP

Magazine
Marque
GNU/Linux Magazine
Numéro
208
|
Mois de parution
octobre 2017
|
Domaines
Résumé
Du code propre et lisible, dans lequel chaque classe reçoit du ciel les composants avec lesquels elle doit travailler, sans avoir à les passer explicitement : c’est l’ambition des outils d’injection de dépendances.