Petite explication...
Pour protéger les process, ils ont tous leur propre espace mémoire. Néanmoins, il est possible de réserver des espaces mémoire partageable entre les process (= Shared Memory).
"Xshm" est une extension du serveur X, qui permet de negocier avec le serveur X pour utiliser de la mémoire partagée avec le programme, pour réduire grandement les temps de transfert des informations, et la consommation mémoire.
(en temps normal, quand tu veux afficher une image, il faut la charger en mémoire, ensuite l'envoyer au serveur X pour l'affichage, donc réservation de deux fois la quantité de mémoire, et transfert via la connection au serveur X dans le deuxième espace.)
Le 'problème' de cette extension, c'est qu'il faut que le toolkit (qt, gtk le font) soit capable de la gerer, puisqu'elle change le mode de fonctionnement. La où les choses se compliquent encore pour le programmeur, c'est qu'elle peut ne pas fonctionner, si l'utilisateur à choisi d'exporter l'affichage ailleurs. D'où nécéssité d'ecrire deux codes différents pour la même chose :-(
Mais quand tu passes des plombes devant un écran, autant qu'il soit agréable à regarder. C'est comme bosser dans un bureau pas crade et sur une chaise confortable.
Joli sujet de debat que voila...
Il faut alors definir ce que l'on appelle agréable.
Veux-tu qu'il soit agréable à regarder ou à utiliser ?
Comme tu le cite, les fenêtres transparentes sont un parfait exemple : c'est nettement plus joli à l'écran, mais si l'on les utilise sérieusement, on se rend compte que l'on perd en lisibilité. Le but serait plutot d'augmenter les contrastes pour le confort de vision.
Et les gens de qt et gtk qui sont fiers d'implémenter l'antialiasing sur les fontes. Grosse erreur ! C'est évident, on se retrouve alors avec un affichage bien plus joli, mais on y perd en lecture, puisque l'on diminue le contraste des caractrères.
On pourrait encore parler du sacro-saint aspect 3D des interfaces graphiques, qui sont nettement plus belles, c'est sur. Mais avec ce fond gris, que l'on ecrives en noir ou en blanc, on se retrouve encore avec trop peu de contrastes...
Enfin bref, tout ca pour dire que toutes les 'pertes de puissance' approtées par les interfaces, c'est sur, on n'en a rien a battre avec la puissance des machine, mais si on y perd en confort d'utilisation, c'est un pas en arrière que l'on franchit...
(mon Atari à 8MHz affiches plus vite les menus déroulants que mon Windows 98 sur un Athlon 800MHz, depuis qu'ils ont eu la lumineuse idée de les animer... merci les gars !)
Le problème, c'est qu'il faudrait un juste milieu. Oui je suis d'accord avec toi, il vaux mieux coder 'sale' pour que ca ne coute pas une fortune, mais AVANT de se poser cette question, les concepteurs d'interface ne devraient ils pas se poser la question de l'utilité de ce qu'ils font ? Je sait qu'il existe des cours d'IHM (interface homme/machine) dans de nombreuse ecoles, et j'espère que l'on leur donne ces bases :)
Internet c'était un truc génial parce que tu pouvais écouter la radio, tout en payant le téléphone
Pour information, c'est dans un sketche d'Anne Roumanof sur l'informatique. Il est assez drole, et (malheureusement) assez vrai :)
Maintenant, elle l'a peut-être repiqué quelque part ?
-1 parceque, tout de même, légèrement HS sur les bord, hein...
Voila un projet interressant, puisqu'il permet d'installer les logiciels que l'on compile sois-meme en les ajoutant a la liste des paquets de la distribution. Rien de tel pour garder une installation propre, puisque ainsi l'on garde une trace de ce qui a été installé, et l'on peut alors supprimer facilement celui-ci. (erreurs, mises a jour, tests, ...)
Si quelqu'un veut bien s'y coller, on pourrait même peut-etre s'en servir pour les LFS ?
j'avoue que non, je n'en suis pas certain, et même je pense qu'il y en a eu d'autre avant.
C'est honteux, mais je me suis servis de ma signature pour faire d'une pierre deux coups, et taper en même temps sur deux choses que je n'apprécie pas beaucoups...
PS: j'ai corrigé, comme tu vois, et je te remercie. C'est entièrement ma faute : je ne devrait pas travailler à des heures avancées de la nuit :) (c'est d'ailleur précisé dans le guide de l'administrateur unix: c'est vers les trois heures du matin que commencent les fatidiques rm -rf /....)
Ce que tu fais remarquer là est tout à fait exacte, et il est bon de le faire remarquer. Cependant, j'aimerais y emettre un bémol.
Ayant la (mal)chance de comprendre un peu l'anglais, j'ai lu le thread en anglais avant d'avoir la nouvelle sur linuxfr. Et, en tombant sur cette nouvelle, justement, j'ai eu l'impression que le contenu du thread n'était pas retranscrit honnetement. Mais j'arretes de palabrer, et j'explique :
- en effet, linux torvalds compare l'évolution des logiciels à celle de l'évolution naturelle. Chose que l'on ne peut faire pour le materiel, à cause de son état figé.
- "Selon lui, Linux n'a jamais été pensé à l'avance. Le contraire l'aurait conduit à l'échec." nous dit la nouvelle. Ce n'est pas exactement ce que nous dit linus. Il nos explique que le fait que linux ait été conçu sans but a atteindre nous à amener à un système qui est partis dans plusieurs directions, et qui ainsi lui à permis d'aller vers plusieurs domaines. Le choix d'une fonction finale ne l'aurait certainement pas conduit à l'echec, mais il ne serait par exemple que devenu un unix classique, peut-etre le meilleur, mais n'aurait pas apporté tous ces boulversement au monde unix, tel que par exemple l'avancée en multimédia, la possibilité d'en faire en système embarqué, que ce soit dans un calculateur ou un PDA, tout en etant utilisable à la fois en bureautique et en sciences par exemple.
- enfin, la citation d'Alan Cox, n'est pas exacte : "on a fait des murs avant de réfléchir sur le ciment" : ce n'est pas exactement ce qu'il dit, puisqu'il ne parle pas du ciment, mais de sa composition chimique. Quand nos ancetres ont construits leurs maisons et cathédrales, ils n'avaient pas la moindre idée de la composition du ciment. Ils ont utilisés celui qui, par expérience (le "test & see"...) celui qui leur semblait le plus solide. Et puis on ne parle pas de tous ces batiments qui se sont écroulés à l'époque, peut-être parceque devant les ruines nos ancêtres savaient déjà tirer les leçons des erreurs et reconstruire...
Enfin, j'aimerais tempérer ton commentaire pour ajouter ceci : il est vrai que maintenant l'on emploi de nombreux ingénieurs à la tache, pour effectuer nombre de calculs pour les choix de matériaux, mais il faut relativiser : les cathédrales sont "trops solides" par rapport à ce que l'on ferait de nos jours, car les calculs sont fait principalement par péché d'avarice, afin d'obtenir la solidité nécéssaire tout en baissant le coup de fabrication. (heureusement, ce n'est pas le cas partout :))
En pratique, je pense qu'un tel site aurait vraiment une utilité. Par contre, il serait bon de rester raisonnable : classer les plus mauvais sources, mais aussi noter les ameliorations des coders incriminés.
Frapper sur les mauvais coders ne les inciteraient pas a continuer a dévellopper des logiciels open source, mais plutôt a rejoindre les projets proprietaires, où personne ne dit rien sur la qualité de leur code... (sans parler des éternelles légendes sur les coders au sources bien obscur, pour justifier et conserver leur place...)
C'est pourquoi je pense que noter les améliorations seraient alors perçue comme une forme d'encouragement, et la communauté complete aurait ainsi a y gagner, sans parler des exemples ainsi fournis aux débutants en recherche de conseils.
[^] # Re: simple question...
Posté par Christophe --- . En réponse à la dépêche Ces "nouveaux" gestionnaires de fenêtres. Évalué à 3.
Petite explication...
Pour protéger les process, ils ont tous leur propre espace mémoire. Néanmoins, il est possible de réserver des espaces mémoire partageable entre les process (= Shared Memory).
"Xshm" est une extension du serveur X, qui permet de negocier avec le serveur X pour utiliser de la mémoire partagée avec le programme, pour réduire grandement les temps de transfert des informations, et la consommation mémoire.
(en temps normal, quand tu veux afficher une image, il faut la charger en mémoire, ensuite l'envoyer au serveur X pour l'affichage, donc réservation de deux fois la quantité de mémoire, et transfert via la connection au serveur X dans le deuxième espace.)
Le 'problème' de cette extension, c'est qu'il faut que le toolkit (qt, gtk le font) soit capable de la gerer, puisqu'elle change le mode de fonctionnement. La où les choses se compliquent encore pour le programmeur, c'est qu'elle peut ne pas fonctionner, si l'utilisateur à choisi d'exporter l'affichage ailleurs. D'où nécéssité d'ecrire deux codes différents pour la même chose :-(
[^] # Re: Un peu comme MS-Windows 1
Posté par Christophe --- . En réponse à la dépêche Ces "nouveaux" gestionnaires de fenêtres. Évalué à 7.
Joli sujet de debat que voila...
Il faut alors definir ce que l'on appelle agréable.
Veux-tu qu'il soit agréable à regarder ou à utiliser ?
Comme tu le cite, les fenêtres transparentes sont un parfait exemple : c'est nettement plus joli à l'écran, mais si l'on les utilise sérieusement, on se rend compte que l'on perd en lisibilité. Le but serait plutot d'augmenter les contrastes pour le confort de vision.
Et les gens de qt et gtk qui sont fiers d'implémenter l'antialiasing sur les fontes. Grosse erreur ! C'est évident, on se retrouve alors avec un affichage bien plus joli, mais on y perd en lecture, puisque l'on diminue le contraste des caractrères.
On pourrait encore parler du sacro-saint aspect 3D des interfaces graphiques, qui sont nettement plus belles, c'est sur. Mais avec ce fond gris, que l'on ecrives en noir ou en blanc, on se retrouve encore avec trop peu de contrastes...
Enfin bref, tout ca pour dire que toutes les 'pertes de puissance' approtées par les interfaces, c'est sur, on n'en a rien a battre avec la puissance des machine, mais si on y perd en confort d'utilisation, c'est un pas en arrière que l'on franchit...
(mon Atari à 8MHz affiches plus vite les menus déroulants que mon Windows 98 sur un Athlon 800MHz, depuis qu'ils ont eu la lumineuse idée de les animer... merci les gars !)
Le problème, c'est qu'il faudrait un juste milieu. Oui je suis d'accord avec toi, il vaux mieux coder 'sale' pour que ca ne coute pas une fortune, mais AVANT de se poser cette question, les concepteurs d'interface ne devraient ils pas se poser la question de l'utilité de ce qu'ils font ? Je sait qu'il existe des cours d'IHM (interface homme/machine) dans de nombreuse ecoles, et j'espère que l'on leur donne ces bases :)
[^] # Re: service publique
Posté par Christophe --- . En réponse à la dépêche La BBC test la diffusion des ses radios en OggVorbis. Évalué à -1.
Pour information, c'est dans un sketche d'Anne Roumanof sur l'informatique. Il est assez drole, et (malheureusement) assez vrai :)
Maintenant, elle l'a peut-être repiqué quelque part ?
-1 parceque, tout de même, légèrement HS sur les bord, hein...
[^] # Re: Oui mais...
Posté par Christophe --- . En réponse à la dépêche installer proprement. Évalué à 2.
Eh bien quel est l'interet de faire des RPMs alors ?
Grace au RPM que tu a fait avec la premiere version, tu peux mettre a jour en :
- enlevant l'ancien RPM (rpm -e), ainsi la vieille version est retirée;
- créant le nouveau RPM.
Si la création du RPM ne sert pas a les supprimer pour les mises a jours, alors je ne vois pas trops l'interet de faire un RPM... :-/
# Installer... et desinstaller !
Posté par Christophe --- . En réponse à la dépêche installer proprement. Évalué à 4.
Si quelqu'un veut bien s'y coller, on pourrait même peut-etre s'en servir pour les LFS ?
[^] # Re: hors-sujet -1
Posté par Christophe --- . En réponse à la dépêche Darwin et Linus. Évalué à 1.
C'est honteux, mais je me suis servis de ma signature pour faire d'une pierre deux coups, et taper en même temps sur deux choses que je n'apprécie pas beaucoups...
PS: j'ai corrigé, comme tu vois, et je te remercie. C'est entièrement ma faute : je ne devrait pas travailler à des heures avancées de la nuit :) (c'est d'ailleur précisé dans le guide de l'administrateur unix: c'est vers les trois heures du matin que commencent les fatidiques rm -rf /....)
[^] # Re: ce qui reste à voir
Posté par Christophe --- . En réponse à la dépêche Darwin et Linus. Évalué à 1.
Ayant la (mal)chance de comprendre un peu l'anglais, j'ai lu le thread en anglais avant d'avoir la nouvelle sur linuxfr. Et, en tombant sur cette nouvelle, justement, j'ai eu l'impression que le contenu du thread n'était pas retranscrit honnetement. Mais j'arretes de palabrer, et j'explique :
- en effet, linux torvalds compare l'évolution des logiciels à celle de l'évolution naturelle. Chose que l'on ne peut faire pour le materiel, à cause de son état figé.
- "Selon lui, Linux n'a jamais été pensé à l'avance. Le contraire l'aurait conduit à l'échec." nous dit la nouvelle. Ce n'est pas exactement ce que nous dit linus. Il nos explique que le fait que linux ait été conçu sans but a atteindre nous à amener à un système qui est partis dans plusieurs directions, et qui ainsi lui à permis d'aller vers plusieurs domaines. Le choix d'une fonction finale ne l'aurait certainement pas conduit à l'echec, mais il ne serait par exemple que devenu un unix classique, peut-etre le meilleur, mais n'aurait pas apporté tous ces boulversement au monde unix, tel que par exemple l'avancée en multimédia, la possibilité d'en faire en système embarqué, que ce soit dans un calculateur ou un PDA, tout en etant utilisable à la fois en bureautique et en sciences par exemple.
- enfin, la citation d'Alan Cox, n'est pas exacte : "on a fait des murs avant de réfléchir sur le ciment" : ce n'est pas exactement ce qu'il dit, puisqu'il ne parle pas du ciment, mais de sa composition chimique. Quand nos ancetres ont construits leurs maisons et cathédrales, ils n'avaient pas la moindre idée de la composition du ciment. Ils ont utilisés celui qui, par expérience (le "test & see"...) celui qui leur semblait le plus solide. Et puis on ne parle pas de tous ces batiments qui se sont écroulés à l'époque, peut-être parceque devant les ruines nos ancêtres savaient déjà tirer les leçons des erreurs et reconstruire...
Enfin, j'aimerais tempérer ton commentaire pour ajouter ceci : il est vrai que maintenant l'on emploi de nombreux ingénieurs à la tache, pour effectuer nombre de calculs pour les choix de matériaux, mais il faut relativiser : les cathédrales sont "trops solides" par rapport à ce que l'on ferait de nos jours, car les calculs sont fait principalement par péché d'avarice, afin d'obtenir la solidité nécéssaire tout en baissant le coup de fabrication. (heureusement, ce n'est pas le cas partout :))
[^] # le hall of shame...
Posté par Christophe --- . En réponse à la dépêche Darwin et Linus. Évalué à 1.
Bin ca existe deja : http://www.ioccc.org/(...)
</joke>
En pratique, je pense qu'un tel site aurait vraiment une utilité. Par contre, il serait bon de rester raisonnable : classer les plus mauvais sources, mais aussi noter les ameliorations des coders incriminés.
Frapper sur les mauvais coders ne les inciteraient pas a continuer a dévellopper des logiciels open source, mais plutôt a rejoindre les projets proprietaires, où personne ne dit rien sur la qualité de leur code... (sans parler des éternelles légendes sur les coders au sources bien obscur, pour justifier et conserver leur place...)
C'est pourquoi je pense que noter les améliorations seraient alors perçue comme une forme d'encouragement, et la communauté complete aurait ainsi a y gagner, sans parler des exemples ainsi fournis aux débutants en recherche de conseils.