L'enfer des dépendances à un nom. Plusieurs, même, mais perso je ne connais que celui donné "affectueusement" par les power user de Windows: DLL Hell.
Donc, tes paquets qui marchent nickel pour toutes les versions de Windows, j'ai envie de dire: "oula, ça dépend. Si tu embarques les 200Mio de données de trucs potentiellement déjà installés sur le système, ouai, ok, parce que sinon bienvenue dans l'enfer des dépendances."
Bon, soyons honnêtes, ce problème existe sous tous les systèmes. En fait, dès lors qu'on utilise de l'édition de liens dynamique, on s'expose aux emmerdes. Version de glibc qui change, par exemple (pour de bonnes raisons: patchs de sécu... d'un autre côté, on aurait peut-être moins besoin de la changer si elle n'avait pas d'extensions et se contentait d'implémenter le standard... mais c'est un autre sujet, très vaste.).
La solution classique sous Windows, c'est de foutre toutes les DLL nécessaires dans le dossier d'install. ça marche, sans bidouille, mais en fait, cette solution est d'une dégueulasserie énorme, qui expose l'utilisateur à des failles de sécurités nommées: hooks. Un attaquant peut du coup très bien mettre une DLL qui à le même nom qu'une DLL système dans ce dossier, pour... hé bien, faire tout ce qui lui plaît. C'est d'ailleurs la technique utilisée par un programme pour améliorer le moteur graphique original de morrowind. Sous les distrib Linux que j'ai testées, cette solution impose d'avoir un script shell pour modifier le LD_LIBRARY_PATH, ou un truc dans le genre, avant de lancer l'exécutable. Mais ça marche.
Bon, en général, on préfère la production de paquets pour les distributions, justement pour éviter l'enfer de l'édition dynamique des liens. Question de choix.
Mais, il existe une autre solution, mille fois plus propre, valide pour TOUS les systèmes: édition des liens de manière statique.
Oui, ça implique de se trimballer toutes les dépendances, mais en plus léger: seuls les symboles réellement utiles seront inclus dans le "paquet", contrairement à ce qui se passe quand on se trimballe les lib dynamiques. Du coup, réduction du risque d'erreurs: on ne peux pas oublier de DLL (le fichier msvcfoo.dll n'à pas été trouvé, réinstaller cette application pourrait corriger le problème... merde, 3 fois que je réinstalle, ça change rien!!!! graaa!!!! SBAF dans l'écran! moi j'ai connu. Et vous?), réduction des risques de sécurité.
Ah, réduction des risques de sécurité... pas si sûr, au final, parce que cette politique est hermétique aux bidouilleurs et admin: on ne peut pas corriger une faille de sécurité sans tout recompiler. Hors, ça, ça implique de compiler à chaque MàJ des dépendances... ce qui représente du travail. Mais ça reste quand même moins sensible que la solution "on embarque toutes les DLLs et basta!": le risque qu'un symbole attaquable soit inclus est plus faible, et on est aussi plus résistants aux hooks.
(Ma) conclusion:
1) faire un paquet portable sous linux, ça se fait. De manière très simple: édition des liens statique (surtout pour cette saleté de gnu libc. D'ailleurs, c'est très drôle de réécrire la commande yes, compiler en statique, et comparer à la taille de gnu yes...).
2) la pratique habituelle des "paquets" Windows à contribué à filer à Windows sa mauvaise réputation en matière de sécurité, rendant vulnérable les applications aux hooks, et donc aux virus. D'un autre côté, rien n'empêche de faire la même merde avec un autre système. La merde n'est pas l'apanage de Windows, mais l'habitude d'en faire me semble nettement plus ancrée dans la culture de ce système. Pas la faute des Windows récents, certes.
3) les systèmes de paquets des distributions Linux classiques sont nettement supérieurs à la méthode de La Rache utilisée sous Windows. Mais, comme toute solution elle implique des inconvénients, dont la faible portabilité fait partie (pour un paquet binaire hein, très important).
Et pour en revenir au sujet de base, à savoir la naissance d'une nouvelle distro basée sur LFS, autrement dit basée sur rien, c'est très bien, ça permets à l'auteur de s'amuser. Et à d'autres de s'amuser avec lui.
Mais personne n'est dupe: cette distro ne pourra jamais concurrencer les ténors actuels et leurs enfants: Debian, Red-Hat, ArchLinux. Pas tout de suite en tout cas, et puis, le seul avantage affiché étant la vitesse supposée, je meurs d'envie de dire: benchmark? tests de charge?
Il me semble aussi stupide de conseiller une telle distro à des nouveaux utilisateurs linux. Mais on ne va pas enfoncer les portes ouvertes quand même, si? Il est évident que la jeunesse (manque de robustesse du au manque de recul et de plateformes de tests) est un défaut, quand on s'adresse à un public non connaisseur.
[^] # Re: pas de systemd, et ?
Posté par freem . En réponse au journal NuTyX, une distribution atypique. Évalué à 4.
L'enfer des dépendances à un nom. Plusieurs, même, mais perso je ne connais que celui donné "affectueusement" par les power user de Windows: DLL Hell.
Donc, tes paquets qui marchent nickel pour toutes les versions de Windows, j'ai envie de dire: "oula, ça dépend. Si tu embarques les 200Mio de données de trucs potentiellement déjà installés sur le système, ouai, ok, parce que sinon bienvenue dans l'enfer des dépendances."
Bon, soyons honnêtes, ce problème existe sous tous les systèmes. En fait, dès lors qu'on utilise de l'édition de liens dynamique, on s'expose aux emmerdes. Version de glibc qui change, par exemple (pour de bonnes raisons: patchs de sécu... d'un autre côté, on aurait peut-être moins besoin de la changer si elle n'avait pas d'extensions et se contentait d'implémenter le standard... mais c'est un autre sujet, très vaste.).
La solution classique sous Windows, c'est de foutre toutes les DLL nécessaires dans le dossier d'install. ça marche, sans bidouille, mais en fait, cette solution est d'une dégueulasserie énorme, qui expose l'utilisateur à des failles de sécurités nommées: hooks. Un attaquant peut du coup très bien mettre une DLL qui à le même nom qu'une DLL système dans ce dossier, pour... hé bien, faire tout ce qui lui plaît. C'est d'ailleurs la technique utilisée par un programme pour améliorer le moteur graphique original de morrowind. Sous les distrib Linux que j'ai testées, cette solution impose d'avoir un script shell pour modifier le LD_LIBRARY_PATH, ou un truc dans le genre, avant de lancer l'exécutable. Mais ça marche.
Bon, en général, on préfère la production de paquets pour les distributions, justement pour éviter l'enfer de l'édition dynamique des liens. Question de choix.
Mais, il existe une autre solution, mille fois plus propre, valide pour TOUS les systèmes: édition des liens de manière statique.
Oui, ça implique de se trimballer toutes les dépendances, mais en plus léger: seuls les symboles réellement utiles seront inclus dans le "paquet", contrairement à ce qui se passe quand on se trimballe les lib dynamiques. Du coup, réduction du risque d'erreurs: on ne peux pas oublier de DLL (le fichier msvcfoo.dll n'à pas été trouvé, réinstaller cette application pourrait corriger le problème... merde, 3 fois que je réinstalle, ça change rien!!!! graaa!!!! SBAF dans l'écran! moi j'ai connu. Et vous?), réduction des risques de sécurité.
Ah, réduction des risques de sécurité... pas si sûr, au final, parce que cette politique est hermétique aux bidouilleurs et admin: on ne peut pas corriger une faille de sécurité sans tout recompiler. Hors, ça, ça implique de compiler à chaque MàJ des dépendances... ce qui représente du travail. Mais ça reste quand même moins sensible que la solution "on embarque toutes les DLLs et basta!": le risque qu'un symbole attaquable soit inclus est plus faible, et on est aussi plus résistants aux hooks.
(Ma) conclusion:
1) faire un paquet portable sous linux, ça se fait. De manière très simple: édition des liens statique (surtout pour cette saleté de gnu libc. D'ailleurs, c'est très drôle de réécrire la commande yes, compiler en statique, et comparer à la taille de gnu yes...).
2) la pratique habituelle des "paquets" Windows à contribué à filer à Windows sa mauvaise réputation en matière de sécurité, rendant vulnérable les applications aux hooks, et donc aux virus. D'un autre côté, rien n'empêche de faire la même merde avec un autre système. La merde n'est pas l'apanage de Windows, mais l'habitude d'en faire me semble nettement plus ancrée dans la culture de ce système. Pas la faute des Windows récents, certes.
3) les systèmes de paquets des distributions Linux classiques sont nettement supérieurs à la méthode de La Rache utilisée sous Windows. Mais, comme toute solution elle implique des inconvénients, dont la faible portabilité fait partie (pour un paquet binaire hein, très important).
Et pour en revenir au sujet de base, à savoir la naissance d'une nouvelle distro basée sur LFS, autrement dit basée sur rien, c'est très bien, ça permets à l'auteur de s'amuser. Et à d'autres de s'amuser avec lui.
Mais personne n'est dupe: cette distro ne pourra jamais concurrencer les ténors actuels et leurs enfants: Debian, Red-Hat, ArchLinux. Pas tout de suite en tout cas, et puis, le seul avantage affiché étant la vitesse supposée, je meurs d'envie de dire: benchmark? tests de charge?
Il me semble aussi stupide de conseiller une telle distro à des nouveaux utilisateurs linux. Mais on ne va pas enfoncer les portes ouvertes quand même, si? Il est évident que la jeunesse (manque de robustesse du au manque de recul et de plateformes de tests) est un défaut, quand on s'adresse à un public non connaisseur.