Fink au secours des Macgeeks
Il y a peu de temps, je faisais connaissance avec la fashion victim de Steve Jobs, le Mac. Après avoir exploré le côté user-friendly, fait joujou avec le Doc (et non, je ne parle pas d’un document Word) et les fenêtres, et finalement me lasser un peu, je vous propose de démarrer en douceur sur une customization un peu plus poussée.
La base dmg, ou l’installation par Aqua
Lorsque l’on acquiert un Mac, et que l’on veut, mettons, installer Firefox, il faut télécharger les sources. Bon ok. Mais une fois les sources téléchargées, on se retrouve avec une fenêtre Finder ouverte, représentant 2 icônes. Une pour Firefox et une pour notre dossier Applications. Et le Finder nous dit de drag and dropper l’un vers l’autre. Ceci fait, l’installation est close.
Très sympa, je vous l’accorde. Il suffit effectivement de faire le chemin inverse (un dossier de Applications vers Trash) pour désinstaller une application. Nous sommes loin de Windows et de sa base de registre. Loin de Linux également, et de ses dépendances et de son déploiement automatique. Oui, mais… Cette manip pourtant simple devient ingérable sur un parc de plusieurs Mac, si l’on veut éviter d’attribuer des privilèges trop grossièrement découpés. En effet, il nécessite que vous veniez en personne, montiez le dmg et fassiez le glissé dans les dossiers qui vont bien. Pas super pratique en fait.
Autre point noir, passer ainsi par le dmg suppose que l’application a été portée explicitement pour Mac. Or, étant donné que Mac possède, à l’heure actuelle, un noyau FreeBSD, du Linux donc, se serait dommage de s’arrêter à la bonne volonté des développeurs.
Fink, ou l’ouverture sur les Unix compliant tools
Fink est un plus qu’un outil. Fink est le nom d’un projet qui a pour but de porter les applications Unix pour Mac.
Pour la version Mac 10.6 (Snow Leopard pour les intimes), il faut passer par les sources de Fink pour pouvoir l’installer. Pas grand’ chose, mais cela nécessite d’avoir XCode et un petite dose de patience. Quelques questions concernant la connectivité et le choix des miroirs et vous êtes parti pour bien 10 minutes de compilation intensive.
Par défaut, Fink utilise le /sw comme répertoire de base. Mais la Communauté a bien fait les choses : en post-installation, il faut exécuter depuis le terminal un script de pathsetup, qui permet de faire en sorte que vous puissiez appeler fink d’où que vous soyez.
La ligne de commande est très simple et propose en plus plusieurs choix de gestion de package : fink, natif, le fameux apt-get de Debian et dselect (qui utilise apt). Les utilisations sont intuitives et le listing est plutôt bien documenté sur le site officiel. La petite distinction entre la méthode apt-get et fink, c’est que fink va chercher sources et binaries, alors que les 2 autres vont chercher seulement les binaries.
Pour avoir une idée de ce qui est disponible et de ce qui est installé actuellement, il suffit de lancer un fink list. Une installation passera par fink install <package>. Et pour plus de customisation, visitez le /sw/etc/fink.conf.
Nice, Smart and Sexy
Et voilà. Avec Fink, vous avez désormais accès à une parpadelle d’application qui ne demandent qu’à vous servir du mieux qu’elles peuvent. Il ne vous reste plus qu’à vous lancer à corps perdu dans l’exploration et les tests de chacune d’entre elles ! Et bien sûr, de déployer les plus pertinente depuis un terminal sur l’ensemble de votre parc Mac via un script maison !
Au final, niveau administration système massive d’un parc Mac, tout n’est pas perdu…
2 Responses to Fink au secours des Macgeeks
Laisser un commentaire
Membre de
Salut, je viens de lire ton article et je souhaite émettre mon point de vue concernant fink (ou macports que j’utilise intensivement). Pour moi c’est juste un bon moyen de porter des tools ou daemon sur Mac Os via un shell. Je ne comprend pas en quoi le système est plus avantageux pour la gestion de parc. Premièrement il oblige l’installation des outils de développement sur des portes de travail. Ensuite un simple scp (ou même mieux son homologue parrallélisé prsync) d’une application dans un volume monté sur le bureau vers le dossier application des postes distant n’est pas suffisante?
Bonjour.
Merci pour ton commentaire qui soulève une bonne question. Il est vrai que l’installation de XCode est un prérequis pour pouvoir utiliser Fink, mais comme ce n’est pas les utilités qui manquent, c’est vrai que je suis passée un peu rapidement sur la contrainte qu’il pouvait impliquer.
Ma position sur la question est la suivante :
- Pour ce qui est des applications qui ne sont pas disponibles en dmg, Fink permet d’une part d’avoir à disposition une même collection d’outil sans avoir à monter son propre miroir, et donc d’éviter les méthodes archaïques de partage et de mise à disposition de sources, de compilation propre au Mac distant, et surtout, de stockage et de classification/update des packages à disposition.
- D’autre part, pour ce qui est du dmg, comme je l’ai souligné un peu plus haut, la première difficulté, c’est justement d’en trouver un. Beaucoup d’applications ne proposent pas de fournir le dmg et passent plutôt un zip ou un tar.gz.
- Ensuite, il est vrai qu’il est possible de scp et de monter un dmg sur un Mac, mais on revient à une manip à faire sur les Macs.
- Et enfin, le scp, c’est vrai que c’est un excellent outil qui trouve sa place assez facilement, mais le problème, c’est que pour que ce soit un minimum automatisé, il faut faire jouer un ensemble de mécanismes impliquant un affaiblissement au niveau SSI.
Les clés SSH aux passphrases vides en mode superuser, c’est quand même un peu discutable quand on parle de sécurité.
En fait, je ne considère pas uniquement Fink comme un outil qui pourrait enrichir l’OS, mais également comme un ensemble de services qui m’éviterait, à moi, ASR, de me prendre la tête avec tout ce qui pourrait rentrer en ligne de compte lors de l’installation de packages, y compris l’aspect mirroir.
Parce qu’en fait, ces contraintes représentent la partie la moins intéressante de l’administration, sont peu reluisantes et n’apportent aucune réelle plue-value. Alors que travailler sur des projets…
En tout cas, ton commentaire est pertinent dans la mesure où il montre qu’il existe effectivement toujours (et heureusement d’ailleurs) d’autres moyens de faire. Merci !