-
S'abonnerAbonnez-vous à nos différents supports -
Magazines à l’unitéCommandez les nouvelles parutions ou complétez votre collection -
Livraison offerte à partir de 50€ d’achat ** Offre valable pour les numéros hors abonnements, livraison en France métropolitaine, appliquée une fois connecté !
GNU/Linux Magazine 271
Programmez votre propre VPN !
- Manipulez les interfaces TUN/TAP
- Renforcez la sécurité avec les capabilities
- Améliorez les performances
9,90 € TTC
Anciens Numéros
BSD Family
p. 06 Créons des ports pour OpenBSD
p. 14 NetBSD & boot PVH : du néant à init(8)
Bas niveau & Reverse
p. 26 Caches CPU : pour vivre heureux, vivons cachés
p. 35 Les codes fantastiques : un zéro pointé
p. 38 Une (autre) pile matérielle pour le modèle bipilaire
WebDev & Réseau
p. 54 Peter et les réseaux virtuels
p. 68 Communication et notification temps réel au sein des applications web
Sécurité & Crypto
p. 80 Le scarabée dort
À quoi peut bien servir un installeur graphique...
... si ce n’est à ajouter des bugs à corriger et du code à maintenir ? Voilà une question dont la réponse relève réellement du mystère pour moi. Le phénomène n’est pourtant pas nouveau et je me souviens très clairement de l’arrivée de ces premiers installeurs clic-clic dans le monde GNU/Linux, il y a bien des années. Tout autant que je me remémore clairement cette même interrogation à cette époque lointaine : mais que pourrait bien fournir un installeur graphique qui ne peut l’être avec un bon vieux dialog ou un code basé sur ncurses ? Une interface graphique ne simplifie rien. N’importe quel utilisateur basculant de Windows à un système digne de ce nom le sait.
La réponse semble typiquement humaine puisqu’il s’agit avant tout, et, je pense, uniquement d’une affaire de perception. Josef Reidinger, présentant Agama (le nouvel installeur OpenSuse) à DevConf.cz, nous explique [1] ainsi qu’un installeur avec une « UI moderne » est important pour faire bonne impression parce que, attention c’est surprenant, il y a des screenshots dans les magazines Linux. Oui, c’est une conférence de juin 2024, pas 2004, et ceci me pousse presque à dire « mauvais magazine, changer de magazine ».
Mais ceci me trouble encore davantage lorsqu’on réalise qu’un installeur, avec un système de qualité, n’est clairement censé être utilisé qu’une seule et unique fois dans la vie d’une machine (sauf pour basculer vers un meilleur OS). Le ratio « utilisation » sur « temps/difficulté de développement » est donc absolument catastrophique par définition. Ce à quoi j’ajouterai, prenez-moi pour un gate keeper ou un intégriste si vous voulez, le fait que si un utilisateur abandonne l’installation parce que l’interface est trop « old school » et lui fait peur, on est en droit de se demander si cela n’est finalement pas pour le mieux. Pour lui-même déjà, mais également pour la communauté de développeurs derrière ce qu’il est sur le point d’installer.
Mais ne vous y trompez pas, je suis d’avis que n’importe qui est libre de développer n’importe quoi, c’est la beauté du logiciel libre. Ligne de commande, menus et fenêtres en mode texte ou interface « clicky-clicky », à chacun ses préférences. C’est juste que, dans le contexte d’un installeur, c’est comme passer des heures à confectionner méticuleusement à la main... des gobelets jetables/recyclables. Quelque chose m’échappe totalement...
Denis Bodor
Le magazine de référence technique pour les développeurs sur systèmes open source et les ingénieurs R&D !
GNU/Linux Magazine s'adresse aux professionnels et aux particuliers désireux de mieux maîtriser les techniques et problématiques liées à la programmation et à l’utilisation de solutions open source. Tous les deux mois avec ses articles techniques, la publication couvre les thématiques suivantes : programmation système, algo, bas niveau, sécurité du code, développement web...
L’autre jour, en passant dans le couloir, j’ai vu Peter apparemment très concentré sur son écran. Je me suis dit qu’il devait faire un truc intéressant, lui. En comparaison, moi j’avais épuisé les derniers travaux intéressants : il ne me restait plus qu’à écrire de la doc ou bien préparer mon entretien annuel. Clairement, la tentation était trop grande et je suis entré dans son bureau pour en savoir plus…
Continuons cette série sur les codes fantastiques avec la découverte d’une implémentation audacieuse de strlen.
Dans un précédent article [1], nous avons découvert qu'il était relativement facile de porter ses créations vers FreeBSD pour les intégrer proprement au système de ports de l'OS. Toujours dans mon exploration de cette fantastique, et incroyablement « propre » famille de systèmes, j'ai abordé OpenBSD serein et confiant, jusqu'à même l'installer sur un système embarqué ainsi que sur une ancienne station Sun Sparc64 [2], remplaçant au passage le NetBSD précédemment installé pour l'occasion. Bien entendu, il fut impossible de ne pas faire connaissance avec le système de ports et de packages, et c'est précisément ce que nous allons aborder ici...
