Mais ça reste très bas niveau, et quand tu veux faire les choses de manière vraiment portable (saisie de chaines, dessin sur du TrueColor, PseudoColor, Palette, Monochrome, chargement d'images, UTF-8, XFT, etc, etc ...), les lignes de codes croissent exponentiellement.
Comme tu le dis, c'est une bibiothèque de bas niveau. Donc évidement, les possibilités sont vastes et le code qu'il faut produire derrière est à sa mesure. Ce qui nous amène très vite à vouloir encapsuler tout cela dans un toolkit quelquonque. Mais justement, je la trouve suffisament élégante et versatile pour permettre à de nombreux produits de faire leur apparition.
C'est un peu comme coder en assembleur. Le X-Lib exclusif devient un peu spartiate dès lors que l'on a l'ambition de coder de grandes applications, mais cette lib n'est pas forcément difficile en elle-même. Juste longue ! :-)
D'autre part, toutes les fonctions de la XLib ou presque sont documentées dans les man pages. Moi je fais un
nm -D /usr/X11R6/lib/libX11.so | grep " T X" | less
histoire de n'en louper aucune.
Quant aux atoms, il s'agit du dictionnaire de la XLib. Un atom est une chaîne de caractères associée à un numéro unique. Cela sert à nommer des ressources. C'est un concept que l'on utilise souvent en bases de données. Il y a une liste générale par serveur X. Donc du coté du compilateur du client, un Atom c'est simplement un entier non signé.
Donc du coup, chaque fois que tu veux te référer à une propriété particulière, tu résouds d'abord son nom complet en son numéro, puis tu utilises celui-ci pour toutes tes requêtes. Cela évite d'avoir soit un nom de fonction différent pour chaque entité, soit une tripotée de #DEFINE écrits en dur dans la X-lib.
Exemple : Tu veux changer le titre d'une fenêtre. Facile :
XStoreName (dpy,win,"Mon nouveau titre");
Où dpy est la connexion vers le serveur X et win le handler de la fenêtre dont tu veux changer le titre. Il existe un certain nombre de fonctions "raccourcis" de ce type pour les opérations les plus triviales. Cependant, le titre d'une fenêtre n'est qu'une des nombreuses propriétés de celles-ci. D'ailleurs, la man page de XStoreName est intitulée « set or read a window’s WM_NAME property ». Cela veut dire qu'il existe une fonction pour gérer toutes les propriétés de manière universelle.
Tu utilises donc XInternAtom (dpy,win,"WM_NAME") pour récupérer une fois pour toutes l'atome qui correspond, et tu changes la valeur de cette propriété (en l'occurence le titre) avec XChangeProperty ().
Tu peux en outre utiliser la commande « xlsatoms » pour lister tous les atomes déjà déclarés. Attention, cette base ne sert toutefois qu'à associer le nom complet d'une ressource à son identifiant, mais en AUCUN CAS à stocker des données.
Moi je fais partie des rares personnes à bien aimer la XLib, qui n'est pas aussi pénible qu'on veut bien le croire, une fois que l'on a bien saisi l'esprit. Il y a juste beaucoup de déclarations à faire en tête du programme, mais le reste se fait relativement aisément ensuite. Je trouve qu'elle est excellente pour apprendre le fonctionnement d'une interface graphique (bien plus que la C.API de Windows par exemple), et notament parce qu'elle introduit un modèle et un environnement objet qui ne s'appuie pas du tout sur le langage.
Je ne connais pas eTags en particulier, mais en programmation C, tu n'as besoin que du .h, sous réserve qu'il soit écrit correctement, pour compiler tes programmes.
Après, à l'édition, il te faudra soit les *.o|*.a pour faire une compilation statique, soit avoir les bibliothèques partagées installées où il faut, et dans ce cas il faut passer l'option -llenomdelalibsanslepréfixeLIB à gcc. Eventuellement -L (en majuscule), si tes biblothèques ne sont pas installées dans des répertoires standard (style /usr/lib).
Ah oui c'est effectivement très instructif ! Donc je résume en gros :
- Il existe les DVD R et DVD RW, qui sont respectivement inscriptibles et réinscriptible. Ca, tout le monde le sait, et c'est pareil pour les CDs.
- Cette norme a été lancée par un forum de 200 fabricants et tout le monde était content.
- Histoire de s'accaparer le marché, les quelques fabricants les plus prestigieux ont décidé de former un consortium et de lancer une nouvelle norme de codage en changeant le "-" en "+". Cela n'influe aucunement sur la capacité de stockage, mais introduit juste une incompatibilité visant à exclure les indésirables.
- Cela a effectivement été le souk pendant quelques temps, la plupart des lecteurs ne reconnaissant que l'ancienne norme, d'autres plus récents uniquement la nouvelle.
- Aujourd'hui, bilan zéro : Tous les lecteurs ou presque reconnaissent les deux formats mais l'on reste obligé de se faire braire avec les deux normes, et de bien vérifier que son lecteur et/ou graveur les reconnaît bien toutes les deux, ou à défaut bien connaître celle qu'il reconnaît.
Evidemment, tout cela reste au conditionnel, mais c'est quand même bien nébuleux pour le consommateur.
D'ailleurs cela me mène à une autre question. Y a-t-il une vraie différence physique entre les DVD-R et DVD+R (meilleure qualité du matériau), ou bien est-ce que l'on s'est tout simplement aperçu que l'on pouvait entre mettre un peu plus sur le même disque et que l'on a pondu deux identifiants différents pour vendre les +R un peu +cheR ?
C'est vraiment pas clair, mais si comme je le pense tu as collé ton su au milieu des autres commandes dans un même script, c'est normal que « ça n'aille pas plus loin ». su ("Substitute User") est fait pour ouvrir un shell sous une identité donnée, par défaut root. Fais un logout dans ce shell et tu verras que ton script exécutera le reste de tes commandes (mais pas en root, cela va de soi).
Tu peux utiliser su -c pour lancer ledit shell en mode non-interactif et lui spécifier la commande à exécuter.
* Tes données ne soient pas dans le cache ? (utiliser fflush())
* Ton programme « traitement » n'ait pas besoin d'avoir l'intégralité de tes résultats pour t'en fournir le bilan (typiquement le cas de sort) ?
J'ajouterais qu'inclure vi.size() directement dans la boucle n'est pas une bonne idée, car il faut réévaluer la méthode à chaque tour de boucle. Moi je préfère :
unsigned int x,y;
J'ai compilé mon kernel (2.6.11.7) en ne configurant quasi rien
Si tu as la flème de retrouver la config initiale de ton système, tu peux aller la chercher dans le répertoire "/boot". Tu copies ce fichier dans ton /home ou dans /tmp, histoire de laisser l'autre tranquille, tu lance un make xconfig (ou autre, selon tes goûts) et tu recharges la config à partir de ton fichier.
Pas de panique, c'est un incident assez fréquent. En général, le système fait son « checkdisk » tout seul. Il le fait même régulièrement au bout de 20 ou 30 démarrages. Quand le filesystem a été arrêté trop violement et qu'il peut y avoir des ambiguïtés, le système te demande de lancer la commande toi-même dans le cas où il y aurait des précautions spéciales à prendre.
# e2fsck /dev/hda1
pour « ext2 filesystem check », est la commande qui fait les vérifs et les réparations. « hda1 » est la partition à vérifier. Fais auparavant un
# mount
pour voir sur quelle est la partition racine ("/" et tous ses sous-répertoires). Passe le bon descripteur à la commande en fonction de ce que tu vois, à la place de /dev/hda1.
librairie ou bibliothèque c'est quoi la différence ?
Une librairie c'est une boutique qui vend notament des livres, des revues, des ouvrages en tout genres et qui peut accessoirement faire office de débit de tabac.
Une bibliothèque c'est avant tout une collection d'ouvrages. Il se trouve qu'en français, le terme intègre le préfixe biblio qui signifie « livre », et que l'on décline en ludothèque, vidéothèque, logithèque ou autre. C'est plus rare en anglais.
Ici, une bibliothèque est une collection de fonctions, et éventuellement de ressources en tous genres (icônes, objets divers, etc.) réunies dans le même fichier, et ce soit sous forme d'objets partagés (*.so), soit sous forme d'objets statiques (*.o) embarqués dans un fichier d'archive (*.a).
Après, pourquoi ne pas dire librairie dans ce cas la ?
Parce que c'est un contresens ! C'est un piège facile mais que l'on rencontre de plus en plus souvent, simplement parce que la plupart des gens ne maîtrisent pas leur propre langue, et qui n'a par conséquent aucune raison d'être « légalisé ».
Le pire exemple est encore le verbe « supporter » : C'est un terme violent en français qui se traduit par to stand en anglais, et comme ces notions existent dans les deux langues, cela induit des ambigüités. Et en plus, c'est vraiment très laid et désagréable à lire. Donc, s'il y a des gens qui se demandent comment traduire ce terme en français :
S'il s'agit d'apporter son appui à une cause ou une personne, on dit « soutenir ».
S'il s'agit de matériel informatique ou d'une configuration particulière, on peut utiliser « prendre en charge » ou (mieux) « reconnaître ».
S'il s'agit d'aide aux utilisateurs, on parlera d'« assistance » plutôt que de support technique ou autre.
Je ne comprends toujours pas pourquoi on ne peut pas faire un système de paquets générique pour toutes les distributions qui gèrerait les dépendances.
Concurrence (ou compétition, à la limite).
C'est pour les mêmes raisons qu'il existe Gnome et KDE en parallèle. On peut s'estimer heureux qu'il n'en existe que deux, mais en un sens, cela respecte quand même le droit à l'alternative.
Pour avoir bossé en intégration/déploiement (donc côté pas dev), j'ai compris que les utilisateurs (ceux qui compte donc) ont exactement l'avis inverse.
Ca, en revanche, c'est vrai. D'ailleurs le seul programme que j'ai écrit pour Windows se passait complètement de bibliothèques. Cela ne veut pas dire pour autant qu'il était entièrement statique, mais qu'il faisait appel à des bibliothèques réputées être toutes fournies par le système. Moralité, un petit exécutable de 164Ko qui pouvait s'exécuter partout sans installation. Il a fait fureur pendant facilement deux ans sur logithèque point fr.
Ceci dit, c'est à ça que servent les installeurs style InstallShield sur Windows ou *.rpm/*.deb sous Gnu/Linux, parce que non seulement ils gèrent les bibliothèques associées, mais aussi tous les fichiers connexes (conf principalement), les dépendances, les mises à jour, et la redoutable base de registre sous Windows.
Faire le procès des bibliothèques partagées, c'est déplacer le problème. Aucun utilisateur ne devrait se trouver avec un *.exe seul sans ses dépendances, à moins de l'avoir piraté (dans ce cas, aucune vergogne), soit parce que le système n'est pas assez souple pour permettre un déploiement facile.
J'ai comme l'impression que la toute puissance du développeur est de plus en plus néfaste pour l'utilisateur. Je me suis bien trouvé con le jour où j'ai dû expliquer l'intérêt de corba à un utilisateur : il n'en a rien à foutre des avantages de l'intégration multi-langages, de la visionunifiée des objets, et comme la configuration des ORB n'est pas unifiée, ben lui il a que des inconvénients.
Ca c'est vrai aussi, mais je trouve que là encore le problème est ailleurs. La multiplication des langages de haut niveau et des couches d'abstractions sont autant de causes potentielles de panne et d'incompatibilité, et ce qui ne profite qu'au programmeur au moment du développement se paye au quotidien par une consommation de ressources excessives (le processeur doit traverser toutes les couches au moindre appel).
Ceci dit, là encore, les bibliothèques partagées sont les amies des utilisateurs comme des développeurs. On faisait déjà le procès des grands éditeurs dans les années 90 lorsque l'on a vu les systèmes d'expoitation et les logiciels les plus populaires occuper de plus en plus de place sur le disque (un ami m'a envoyé Windows 1.0 par mail :-) ). Maintenant imagine un peu que tous les logiciels soient statiques : L'équivalent d'un système d'exploitation entier dans chacune de tes applications. Un disque dur de 15To ne suffirait pas, et accessoirement ton OS ne servirait plus à rien. Avec des libs partagées, le code de ladite bibliothèque n'occupe qu'une seule fois sa place non seulement sur le disque, mais également en mémoire (mapping).
En plus, le code partagé se trouve même là où tu ne l'attends pas : Quand une application ouvre une fenêtre, c'est toujours la même et cela te paraît normal : C'est Windows (ou GTK/Qt sous Linux) qui s'occupe de la construire, pas l'application.
[^] # Re: XLib
Posté par Obsidian . En réponse au message Programmation Xlib. Évalué à 2.
Comme tu le dis, c'est une bibiothèque de bas niveau. Donc évidement, les possibilités sont vastes et le code qu'il faut produire derrière est à sa mesure. Ce qui nous amène très vite à vouloir encapsuler tout cela dans un toolkit quelquonque. Mais justement, je la trouve suffisament élégante et versatile pour permettre à de nombreux produits de faire leur apparition.
C'est un peu comme coder en assembleur. Le X-Lib exclusif devient un peu spartiate dès lors que l'on a l'ambition de coder de grandes applications, mais cette lib n'est pas forcément difficile en elle-même. Juste longue ! :-)
# XLib
Posté par Obsidian . En réponse au message Programmation Xlib. Évalué à 3.
http://www.google.fr/search?hl=fr&q=XLib&btnG=Recherche+Goo(...)
Et si tu restreins aux pages francophones, tu trouves beaucoup de trucs aussi sympas. Pendant un temps, j'ai beaucoup trainé sur http://www.u-picardie.fr/~ferment/xwindow/(...) .
D'autre part, toutes les fonctions de la XLib ou presque sont documentées dans les man pages. Moi je fais un
nm -D /usr/X11R6/lib/libX11.so | grep " T X" | less
histoire de n'en louper aucune.
Quant aux atoms, il s'agit du dictionnaire de la XLib. Un atom est une chaîne de caractères associée à un numéro unique. Cela sert à nommer des ressources. C'est un concept que l'on utilise souvent en bases de données. Il y a une liste générale par serveur X. Donc du coté du compilateur du client, un Atom c'est simplement un entier non signé.
Donc du coup, chaque fois que tu veux te référer à une propriété particulière, tu résouds d'abord son nom complet en son numéro, puis tu utilises celui-ci pour toutes tes requêtes. Cela évite d'avoir soit un nom de fonction différent pour chaque entité, soit une tripotée de #DEFINE écrits en dur dans la X-lib.
Exemple : Tu veux changer le titre d'une fenêtre. Facile :
XStoreName (dpy,win,"Mon nouveau titre");
Où dpy est la connexion vers le serveur X et win le handler de la fenêtre dont tu veux changer le titre. Il existe un certain nombre de fonctions "raccourcis" de ce type pour les opérations les plus triviales. Cependant, le titre d'une fenêtre n'est qu'une des nombreuses propriétés de celles-ci. D'ailleurs, la man page de XStoreName est intitulée « set or read a window’s WM_NAME property ». Cela veut dire qu'il existe une fonction pour gérer toutes les propriétés de manière universelle.
Tu utilises donc XInternAtom (dpy,win,"WM_NAME") pour récupérer une fois pour toutes l'atome qui correspond, et tu changes la valeur de cette propriété (en l'occurence le titre) avec XChangeProperty ().
Tu peux en outre utiliser la commande « xlsatoms » pour lister tous les atomes déjà déclarés. Attention, cette base ne sert toutefois qu'à associer le nom complet d'une ressource à son identifiant, mais en AUCUN CAS à stocker des données.
Moi je fais partie des rares personnes à bien aimer la XLib, qui n'est pas aussi pénible qu'on veut bien le croire, une fois que l'on a bien saisi l'esprit. Il y a juste beaucoup de déclarations à faire en tête du programme, mais le reste se fait relativement aisément ensuite. Je trouve qu'elle est excellente pour apprendre le fonctionnement d'une interface graphique (bien plus que la C.API de Windows par exemple), et notament parce qu'elle introduit un modèle et un environnement objet qui ne s'appuie pas du tout sur le langage.
# Et ?
Posté par Obsidian . En réponse au message etags et .h. Évalué à 1.
Après, à l'édition, il te faudra soit les *.o|*.a pour faire une compilation statique, soit avoir les bibliothèques partagées installées où il faut, et dans ce cas il faut passer l'option -llenomdelalibsanslepréfixeLIB à gcc. Eventuellement -L (en majuscule), si tes biblothèques ne sont pas installées dans des répertoires standard (style /usr/lib).
# Fautes
Posté par Obsidian . En réponse au journal Réforme de la netiquette sur LinuxFr. Évalué à 6.
"Aucune" : Quantité nulle.
[^] # Re: DVD +R et DVD - R
Posté par Obsidian . En réponse au message Graveur DVD. Évalué à 3.
- Il existe les DVD R et DVD RW, qui sont respectivement inscriptibles et réinscriptible. Ca, tout le monde le sait, et c'est pareil pour les CDs.
- Cette norme a été lancée par un forum de 200 fabricants et tout le monde était content.
- Histoire de s'accaparer le marché, les quelques fabricants les plus prestigieux ont décidé de former un consortium et de lancer une nouvelle norme de codage en changeant le "-" en "+". Cela n'influe aucunement sur la capacité de stockage, mais introduit juste une incompatibilité visant à exclure les indésirables.
- Cela a effectivement été le souk pendant quelques temps, la plupart des lecteurs ne reconnaissant que l'ancienne norme, d'autres plus récents uniquement la nouvelle.
- Aujourd'hui, bilan zéro : Tous les lecteurs ou presque reconnaissent les deux formats mais l'on reste obligé de se faire braire avec les deux normes, et de bien vérifier que son lecteur et/ou graveur les reconnaît bien toutes les deux, ou à défaut bien connaître celle qu'il reconnaît.
Evidemment, tout cela reste au conditionnel, mais c'est quand même bien nébuleux pour le consommateur.
[^] # Re: DVD +R et DVD - R
Posté par Obsidian . En réponse au message Graveur DVD. Évalué à 3.
[^] # Re: Sois plus clair.
Posté par Obsidian . En réponse au message pas de su en bash ?. Évalué à 3.
man su
et
http://www.google.fr/search?hl=fr&q=Substitute+User&btnG=Re(...)
# Sois plus clair.
Posté par Obsidian . En réponse au message pas de su en bash ?. Évalué à 4.
Tu peux utiliser su -c pour lancer ledit shell en mode non-interactif et lui spécifier la commande à exécuter.
Mieux, tu peux utiliser sudo.
# Commençons par le début
Posté par Obsidian . En réponse au message Un pipeline, deux pipelines, trois pipelines.... Évalué à 4.
* Tes données ne soient pas dans le cache ? (utiliser fflush())
* Ton programme « traitement » n'ait pas besoin d'avoir l'intégralité de tes résultats pour t'en fournir le bilan (typiquement le cas de sort) ?
[^] # Re: et le nouveau nom ?
Posté par Obsidian . En réponse à la dépêche Mandriva annonce l'acquisition des principaux actifs de Lycoris. Évalué à 3.
[^] # Re: Faites vos jeux
Posté par Obsidian . En réponse à la dépêche Mandriva annonce l'acquisition des principaux actifs de Lycoris. Évalué à -1.
http://linuxfr.org/2005/04/10/18697.html(...)
[^] # Re: Politique de grand papa
Posté par Obsidian . En réponse au journal [HS] politique : emplois. Évalué à 2.
Chomsky, c'est un diminutif pour chômeur ?
# Des indices ?
Posté par Obsidian . En réponse au message anjuta et les vector. Évalué à 3.
Commençons par le début (dans le contexte actuel) : Maîtrises-tu les templates ?
[^] # Re: petit exemple
Posté par Obsidian . En réponse au message anjuta et les vector. Évalué à 2.
unsigned int x,y;
for (x=0,y=vi.size();x<y;++x) ...
[^] # Re: Bientôt un nouveau nom ?
Posté par Obsidian . En réponse à la dépêche Mandriva annonce l'acquisition des principaux actifs de Lycoris. Évalué à -1.
[^] # Re: Bientôt un nouveau nom ?
Posté par Obsidian . En réponse à la dépêche Mandriva annonce l'acquisition des principaux actifs de Lycoris. Évalué à 1.
# Bientôt un nouveau nom ?
Posté par Obsidian . En réponse à la dépêche Mandriva annonce l'acquisition des principaux actifs de Lycoris. Évalué à 10.
# La flème mène au coté obscur (... enfin cela dépend).
Posté par Obsidian . En réponse au message Impossible d'inscrire un module. Évalué à 3.
Si tu as la flème de retrouver la config initiale de ton système, tu peux aller la chercher dans le répertoire "/boot". Tu copies ce fichier dans ton /home ou dans /tmp, histoire de laisser l'autre tranquille, tu lance un make xconfig (ou autre, selon tes goûts) et tu recharges la config à partir de ton fichier.
[^] # Re: Filesystem check
Posté par Obsidian . En réponse au message Pb de boot sur RedHat !. Évalué à 2.
A noter toutefois que l'opération peut-être à répéter pour les différentes partitions Linux (celles montées sur /home, /var, etc.).
Cela peut-être une bonne idée de tout vérifier en une fois.
# Filesystem check
Posté par Obsidian . En réponse au message Pb de boot sur RedHat !. Évalué à 3.
# e2fsck /dev/hda1
pour « ext2 filesystem check », est la commande qui fait les vérifs et les réparations. « hda1 » est la partition à vérifier. Fais auparavant un
# mount
pour voir sur quelle est la partition racine ("/" et tous ses sous-répertoires). Passe le bon descripteur à la commande en fonction de ce que tu vois, à la place de /dev/hda1.
[^] # Re: Position des paramètres
Posté par Obsidian . En réponse au message 2 carte reseau.... Évalué à 2.
# Position des paramètres
Posté par Obsidian . En réponse au message 2 carte reseau.... Évalué à 2.
c'est "ifconfig eth1 10.0.0.1 netmask 255.0.0.0 up" qu'il faut écrire.
Après pour les fichiers de conf, il est possible qu'il te faille utiliser la MacAdress pour les différencier ...
[^] # Re: Library or not bibliothèque ?
Posté par Obsidian . En réponse au journal Fonctionnement du linker dynamic sous linux. Évalué à 3.
?
s/Or/Hors/ ?
Une librairie c'est une boutique qui vend notament des livres, des revues, des ouvrages en tout genres et qui peut accessoirement faire office de débit de tabac.
Une bibliothèque c'est avant tout une collection d'ouvrages. Il se trouve qu'en français, le terme intègre le préfixe biblio qui signifie « livre », et que l'on décline en ludothèque, vidéothèque, logithèque ou autre. C'est plus rare en anglais.
Ici, une bibliothèque est une collection de fonctions, et éventuellement de ressources en tous genres (icônes, objets divers, etc.) réunies dans le même fichier, et ce soit sous forme d'objets partagés (*.so), soit sous forme d'objets statiques (*.o) embarqués dans un fichier d'archive (*.a).
Parce que c'est un contresens ! C'est un piège facile mais que l'on rencontre de plus en plus souvent, simplement parce que la plupart des gens ne maîtrisent pas leur propre langue, et qui n'a par conséquent aucune raison d'être « légalisé ».
Le pire exemple est encore le verbe « supporter » : C'est un terme violent en français qui se traduit par to stand en anglais, et comme ces notions existent dans les deux langues, cela induit des ambigüités. Et en plus, c'est vraiment très laid et désagréable à lire. Donc, s'il y a des gens qui se demandent comment traduire ce terme en français :
S'il s'agit d'apporter son appui à une cause ou une personne, on dit « soutenir ».
S'il s'agit de matériel informatique ou d'une configuration particulière, on peut utiliser « prendre en charge » ou (mieux) « reconnaître ».
S'il s'agit d'aide aux utilisateurs, on parlera d'« assistance » plutôt que de support technique ou autre.
[^] # Re: En voila une drôle de question !
Posté par Obsidian . En réponse au journal Fonctionnement du linker dynamic sous linux. Évalué à 2.
Concurrence (ou compétition, à la limite).
C'est pour les mêmes raisons qu'il existe Gnome et KDE en parallèle. On peut s'estimer heureux qu'il n'en existe que deux, mais en un sens, cela respecte quand même le droit à l'alternative.
[^] # Re: En voila une drôle de question !
Posté par Obsidian . En réponse au journal Fonctionnement du linker dynamic sous linux. Évalué à 3.
Ca, en revanche, c'est vrai. D'ailleurs le seul programme que j'ai écrit pour Windows se passait complètement de bibliothèques. Cela ne veut pas dire pour autant qu'il était entièrement statique, mais qu'il faisait appel à des bibliothèques réputées être toutes fournies par le système. Moralité, un petit exécutable de 164Ko qui pouvait s'exécuter partout sans installation. Il a fait fureur pendant facilement deux ans sur logithèque point fr.
Ceci dit, c'est à ça que servent les installeurs style InstallShield sur Windows ou *.rpm/*.deb sous Gnu/Linux, parce que non seulement ils gèrent les bibliothèques associées, mais aussi tous les fichiers connexes (conf principalement), les dépendances, les mises à jour, et la redoutable base de registre sous Windows.
Faire le procès des bibliothèques partagées, c'est déplacer le problème. Aucun utilisateur ne devrait se trouver avec un *.exe seul sans ses dépendances, à moins de l'avoir piraté (dans ce cas, aucune vergogne), soit parce que le système n'est pas assez souple pour permettre un déploiement facile.
Ca c'est vrai aussi, mais je trouve que là encore le problème est ailleurs. La multiplication des langages de haut niveau et des couches d'abstractions sont autant de causes potentielles de panne et d'incompatibilité, et ce qui ne profite qu'au programmeur au moment du développement se paye au quotidien par une consommation de ressources excessives (le processeur doit traverser toutes les couches au moindre appel).
Ceci dit, là encore, les bibliothèques partagées sont les amies des utilisateurs comme des développeurs. On faisait déjà le procès des grands éditeurs dans les années 90 lorsque l'on a vu les systèmes d'expoitation et les logiciels les plus populaires occuper de plus en plus de place sur le disque (un ami m'a envoyé Windows 1.0 par mail :-) ). Maintenant imagine un peu que tous les logiciels soient statiques : L'équivalent d'un système d'exploitation entier dans chacune de tes applications. Un disque dur de 15To ne suffirait pas, et accessoirement ton OS ne servirait plus à rien. Avec des libs partagées, le code de ladite bibliothèque n'occupe qu'une seule fois sa place non seulement sur le disque, mais également en mémoire (mapping).
En plus, le code partagé se trouve même là où tu ne l'attends pas : Quand une application ouvre une fenêtre, c'est toujours la même et cela te paraît normal : C'est Windows (ou GTK/Qt sous Linux) qui s'occupe de la construire, pas l'application.