Non, le MPEG-2 ne le fait pas. Ce que fait le MPEG-2 est très loin de cela. Il fait à peine de la Motion Compensation, ce qui est loin de ce dont on parle ici. Seule le MPEG-4 apporte les concepts pour les objets. Et ce n'est pas la partie qui est implémentée dans le DivX, ni dans le MPEG-4 de Microsoft, car elle est trops gourmande en ressources.
Le Motion Estimator/Motion Predictor qui est implémenté dans le MPEG n'a pas grand chose à voir avec la détection de mouvement des objets. D'ailleurs, la norme elle même rapelle que l'information qui en est issue ne peut pas être utilisée pour faire de l'étude de mouvement.
Je ne rentre pas dans les détails techniques, parcequ'ils sont chiants, mais si tu est intéréssé, il reste toujours la messagerie :)
Les objets plats, pour les personnages par exemple;
Les objets en 3D, pour par exemple les meubles.
Si l'on arrives a faire maintenant sans problème le premier point, comme cela est cité dans un post ci-dessous, la société semble commencer à se diriger dans le domaine du deuxième point.
Tiens, c'est curieux, mais ça me rapelles quelquechose...
J'avais eu l'occasion de lire quelques documentations sur le MPEG-4 (le vrai), et cette notion, même si aucun logiciel ne l'utilise encore, était déjà présente. Il semble d'après la norme officielle que l'on puisse avoir les mêmes concepts dans le MPEG4.
Pourquoi n'est-ce pas utilisé ? Pour la raison très simple que la recherche d'objet est une procédure très complexe, donc plus que gourmande en temps machine. Impossible de faire de la compression à la volée...
Le concept n'est donc a priori pas nouveau (je doutes fort qu'ils puissent déposer un brever sur quelquechose qui est déjà une norme ISO), mais cette société semble avoir implémenté cela dans un programme...
[je ne donnerais pas plus d'info, car en ce moment les DNS de wanadoo ne semblent pas d'humeur à me répondre, donc la navigation sur internet s'en trouve quelque peu... réduite...]
Heu... ça te gênes pas de donner ton mot de passe à chaque fois ? Et pis l'idée même de lancer un process en root quand ce n'est pas nécéssaire...
Je te propose ceci :
Crée un nouveau groupe. Ce groupe va autoriser tous les utilisateurs que tu autorise à utiliser le graveur.
Rajoutes toi dans ce groupe. Oui, bon, c'était évident ça :)
Donne le périphérique au groupe. Après tout, y'a que eux qui en ont besoin, donc... chown .group /dev/sg..
Donne leur les droits d'accès. chmod g=rw /dev/sg..
Et voila, c'est fini :) A partir de maintenant, tous les utilisateurs dans ce groupe peuvent accéder au graveur, et ce sans avoir besoin de lancer le programme en root.
Et pis... lancer xcdroast en root... quelle drole d'idée : t'as essayé de graver l'iso qui s'appelle /etc/shadow ? si tu le peux, tues users le peuvent aussi :(
Motivé par ma curiosité, j'ai vérifié la nature du patch. J'en ai retiré l'information suivante :
La seule différence est au niveau de l'adresse IP destination. En effet, le "trou de sécurité" consistait en l'ouverture du port pour tout le réseau, alors que maintenant, le port est ouvert uniquement pour la machine qui est connecté au serveur IRC et qui à envoyé la commande DCC.
Par rapport à ton point de vue et ton exemple, je concluerais donc qu'il est toujours possible de faire des trous dans le pare-feu grâce à ce module. Mais si l'on réfléchit un peu, on voie que malheureusement c'est son but. Il suppose en fait que la partie interne du réseau soit de confiance. (ie: pas d'utilisateurs qui puissent avoir les droits root, et chacun ayant une notion de savoir vivre...)
Pour terminer, je dirais que de toutes manière, la seule chose qui devrait être dynamique sur un pare-feu, c'est la fermeture automatique de port, par exemple en cas de détection de port scan, mais certainement pas l'ouverture de ports.
PS: je pense que ta remarque devrait être mise en bonne place dans les guides d'introduction à la sécurité pour Linux, afin que les administrateurs soient conscient de cela.
heu... quand je lis les commentaires si dessus, je les trouves un peu alarmants... :)
à les lire, on dirait une mise en péril de la sécurité complète :)
La faille est lasuivante :
Le module 'espionne' les connections IRC pour y détecter les demandes de connections directs (DCC)
Quand il en voie, il ouvre alors le port correspondant dans le pare-feu. La 'faille' est qu'il l'ouvre pour *toutes* les adresses, au lieu de seulement celle demandée.
Alors je me pose la question :
Au niveau exploitation, ça donne quoi ?
Eh bien... pas grand chose. Cela veut dire que n'importe qui peut donc passer le pare-feu à travers ce port... àcondition de le connaitre, déjà. Et d'avoir quelqu'un qui écoute de l'autre côté.
Pour conclure, je ne dirait pas que cette faille est inexploitable, mais je doute que l'on puisse en tirer vraiment partie... (sauf coup de chance, et en connaissant l'architecture réseau derrière...)
La société, qui cesse ses activité, M-Pixel semblerait ne pas avoir de lien avec I2BP. Son fondateur, Patrick Haddad, à envoyé un message au journal du net pour clarifier la situation :
Et zut, moi qui venait de m'acheter un pack de 10 boites de disquettes vierges... :-(
<mode type="petites_annonces">
Suite liquidation, vend boites de disquettes HD vierges. Prix à débatre...
</mode>
(-1: sai pa bien de se moquer...)
C'est bien les lenteurs de l'administration... comment ils ont fait pour pas être liquidés depuis longtemps ? Et leurs brevets, y vont tomber dans le domaine public, donc... chouette :)
Sauf que je ne suis pas sur que cet argument soit recevable devant un tribunal... L'antériorité c'est bien, mais dans la pratique c'est toujours trops compliqué à prouver.
Le principe du temps réel, c'est que l'on connait le temps exact que va mettre telle ou telle action. Donc c'est içi un exemple pratique : on est sur du débit dont on dispose pour enregistrer par exemple la vidéo...
(promis, je change ma signature. bientôt. dès que je sait quoi mettre d'autre...)
Par ailleurs, les gusses qui bidouillaient des postes TSF il y a quelques décennies utilisaient déjà le mot « hacker » pour se décrire.
Comme tu le fait remarquer, ce mot n'est pas nouveau. Il a toujours eu la même signification, celle des gens qui veulent aller plus loin, qui sont passionnés, et doués dans leur domaine. par contre, quand tu dis :
Sa reprise par les informaticiens, puis par les pirates, témoigne que ce mot a successivement élargi son champ sémantique
je ne suis pas du tout d'accord avec toi. Il n'a certainement pas été repris par les informaticiens. Bien au contraire, c'est parceque l'on a retrouvé ces qualités chez certains informaticiens que l'on les a qualifié avec ce mot, donc sans aucun changement de sens.
Pour ce qui est de la 'reprise' par les pirates, elle est tout autre : à cette époque, il n'y avait pas de scr1pt k1dd13s, les bon informaticiens étant plus rares. Les pirates n'avaient alors pour réussir que leurs capacités, donc oui, ils étaient des hackers.
Il ne s'agit pas ici d'un élargissement de sens, mais d'un détournement de celui-ci.
Maintenant, je n'ai pas l'intention de commencer une guerre à ce sujet. Si "le peuple" à décidé de lui coller cette conotation négative, eh bien tant pis, il nous reste le terme de gourou...
Il s'agit d'ELKS, The Embeddable Linux Kernel Subset. Je te laisse le soin de consulter la page pour les informations détaillées. Il s'agit d'un dévellopement de Linux pour les systèmes à base de 8086 et 80286. Je ne sait pas si tu trouvera ton bonheur la-dedans, mais en tout cas tu pourra t'amuser avec :-)
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: Faut pas trop cracher dans le Maelström...
Posté par Christophe --- . En réponse à la dépêche Un nouveau site pour les thèmes. Évalué à -3.
heu... et t'en est ou ?
[-1] paskeu sai une private joke :)
[^] # Re: Film numérique : pour cinema numerique
Posté par Christophe --- . En réponse à la dépêche L'âge de glace. Évalué à 2.
Il n'y en a certainement pas qu'un en france, puisqu'il y a au moins une salle à grenoble.
(NEF-Chavant pour les connaisseurs)
[^] # Re: Le mpeg 2 le fait déjà
Posté par Christophe --- . En réponse à la dépêche Révolution dans la compression vidéo ?. Évalué à 4.
[^] # Re: Les objets de l'image
Posté par Christophe --- . En réponse à la dépêche Révolution dans la compression vidéo ?. Évalué à 3.
Le Motion Estimator/Motion Predictor qui est implémenté dans le MPEG n'a pas grand chose à voir avec la détection de mouvement des objets. D'ailleurs, la norme elle même rapelle que l'information qui en est issue ne peut pas être utilisée pour faire de l'étude de mouvement.
Je ne rentre pas dans les détails techniques, parcequ'ils sont chiants, mais si tu est intéréssé, il reste toujours la messagerie :)
[^] # Re: Les objets de l'image
Posté par Christophe --- . En réponse à la dépêche Révolution dans la compression vidéo ?. Évalué à 10.
Ce qui m'a permis de trouver ceci, qui expliques bien les idées générales :
http://mpeg.telecomitalialab.com/standards/mpeg-4/mpeg-4.htm(...)
Le principe est que l'on décompose une image en plusieurs morceaux :
Si l'on arrives a faire maintenant sans problème le premier point, comme cela est cité dans un post ci-dessous, la société semble commencer à se diriger dans le domaine du deuxième point.
# Les objets de l'image
Posté par Christophe --- . En réponse à la dépêche Révolution dans la compression vidéo ?. Évalué à 10.
J'avais eu l'occasion de lire quelques documentations sur le MPEG-4 (le vrai), et cette notion, même si aucun logiciel ne l'utilise encore, était déjà présente. Il semble d'après la norme officielle que l'on puisse avoir les mêmes concepts dans le MPEG4.
Pourquoi n'est-ce pas utilisé ? Pour la raison très simple que la recherche d'objet est une procédure très complexe, donc plus que gourmande en temps machine. Impossible de faire de la compression à la volée...
Le concept n'est donc a priori pas nouveau (je doutes fort qu'ils puissent déposer un brever sur quelquechose qui est déjà une norme ISO), mais cette société semble avoir implémenté cela dans un programme...
[je ne donnerais pas plus d'info, car en ce moment les DNS de wanadoo ne semblent pas d'humeur à me répondre, donc la navigation sur internet s'en trouve quelque peu... réduite...]
[^] # Re: login screen?
Posté par Christophe --- . En réponse à la dépêche Faille importante sous UNIX. Évalué à 1.
Je te propose ceci :
Et voila, c'est fini :) A partir de maintenant, tous les utilisateurs dans ce groupe peuvent accéder au graveur, et ce sans avoir besoin de lancer le programme en root.
Et pis... lancer xcdroast en root... quelle drole d'idée : t'as essayé de graver l'iso qui s'appelle /etc/shadow ? si tu le peux, tues users le peuvent aussi :(
[-1: car je suis vraiment off-topic, là...]
[^] # Use the source, Luke !
Posté par Christophe --- . En réponse à la dépêche Trou de sécurité dans Netfilter. Évalué à 1.
La seule différence est au niveau de l'adresse IP destination. En effet, le "trou de sécurité" consistait en l'ouverture du port pour tout le réseau, alors que maintenant, le port est ouvert uniquement pour la machine qui est connecté au serveur IRC et qui à envoyé la commande DCC.
Par rapport à ton point de vue et ton exemple, je concluerais donc qu'il est toujours possible de faire des trous dans le pare-feu grâce à ce module. Mais si l'on réfléchit un peu, on voie que malheureusement c'est son but. Il suppose en fait que la partie interne du réseau soit de confiance. (ie: pas d'utilisateurs qui puissent avoir les droits root, et chacun ayant une notion de savoir vivre...)
Pour terminer, je dirais que de toutes manière, la seule chose qui devrait être dynamique sur un pare-feu, c'est la fermeture automatique de port, par exemple en cas de détection de port scan, mais certainement pas l'ouverture de ports.
PS: je pense que ta remarque devrait être mise en bonne place dans les guides d'introduction à la sécurité pour Linux, afin que les administrateurs soient conscient de cela.
# Précisions sur la faille
Posté par Christophe --- . En réponse à la dépêche Trou de sécurité dans Netfilter. Évalué à 10.
à les lire, on dirait une mise en péril de la sécurité complète :)
La faille est lasuivante :
Le module 'espionne' les connections IRC pour y détecter les demandes de connections directs (DCC)
Quand il en voie, il ouvre alors le port correspondant dans le pare-feu. La 'faille' est qu'il l'ouvre pour *toutes* les adresses, au lieu de seulement celle demandée.
Alors je me pose la question :
Au niveau exploitation, ça donne quoi ?
Eh bien... pas grand chose. Cela veut dire que n'importe qui peut donc passer le pare-feu à travers ce port... àcondition de le connaitre, déjà. Et d'avoir quelqu'un qui écoute de l'autre côté.
Pour conclure, je ne dirait pas que cette faille est inexploitable, mais je doute que l'on puisse en tirer vraiment partie... (sauf coup de chance, et en connaissant l'architecture réseau derrière...)
# Il semble qu'il y ait un petit amalgame...
Posté par Christophe --- . En réponse à la dépêche I2PB suite... et fin!. Évalué à 10.
http://www.journaldunet.com/corrections.shtml(...)
Pour ceux qui n'ont pas envie de le lire, en gros :
(Ca n'est la que la retranscription de son message, je ne sait pas ce qu'il en est concretement concernant la technologie de M-Pixel.)
# Aaaaargh !!!
Posté par Christophe --- . En réponse à la dépêche I2PB suite... et fin!. Évalué à 3.
<mode type="petites_annonces">
Suite liquidation, vend boites de disquettes HD vierges. Prix à débatre...
</mode>
(-1: sai pa bien de se moquer...)
C'est bien les lenteurs de l'administration... comment ils ont fait pour pas être liquidés depuis longtemps ? Et leurs brevets, y vont tomber dans le domaine public, donc... chouette :)
[^] # Re: Poubelle.
Posté par Christophe --- . En réponse à la dépêche APT, rpmi et autres brevetés ?. Évalué à 0.
[^] # Re: Apportez vos cables rj45 et des multiprises.
Posté par Christophe --- . En réponse à la dépêche LIP à Charleroi le 9/02/2002. Évalué à -10.
heu... si tout le monde ramène son hub, qui ramène les cables RJ45 pour l'uplink ? ça va être le bordel...
</joke>
peut-être auraient-ils dû écrire "apportez vos multiprises et vos cables RJ45" ?
<troll>
Bah, c'est nul, chacun devrait ramener sa fibre optique, Gigabit roulaize !!!
</troll>
Bon, -1, car c'est vraiment pourrir de l'espace disque sur les serveurs à fabien pour rien...
[^] # Re: Mon expérience perso...
Posté par Christophe --- . En réponse à la dépêche Systèmes de fichiers journalisé sur Linux. Évalué à 10.
bah, si, justement. C'est bien ça le temps réel :
Le principe du temps réel, c'est que l'on connait le temps exact que va mettre telle ou telle action. Donc c'est içi un exemple pratique : on est sur du débit dont on dispose pour enregistrer par exemple la vidéo...
(promis, je change ma signature. bientôt. dès que je sait quoi mettre d'autre...)
[^] # Re: Jargon
Posté par Christophe --- . En réponse à la dépêche Utilisez Un Firewall Linux pour se défendre des hackers. Évalué à 3.
Comme tu le fait remarquer, ce mot n'est pas nouveau. Il a toujours eu la même signification, celle des gens qui veulent aller plus loin, qui sont passionnés, et doués dans leur domaine. par contre, quand tu dis :
Sa reprise par les informaticiens, puis par les pirates, témoigne que ce mot a successivement élargi son champ sémantique
je ne suis pas du tout d'accord avec toi. Il n'a certainement pas été repris par les informaticiens. Bien au contraire, c'est parceque l'on a retrouvé ces qualités chez certains informaticiens que l'on les a qualifié avec ce mot, donc sans aucun changement de sens.
Pour ce qui est de la 'reprise' par les pirates, elle est tout autre : à cette époque, il n'y avait pas de scr1pt k1dd13s, les bon informaticiens étant plus rares. Les pirates n'avaient alors pour réussir que leurs capacités, donc oui, ils étaient des hackers.
Il ne s'agit pas ici d'un élargissement de sens, mais d'un détournement de celui-ci.
Maintenant, je n'ai pas l'intention de commencer une guerre à ce sujet. Si "le peuple" à décidé de lui coller cette conotation négative, eh bien tant pis, il nous reste le terme de gourou...
[^] # Vive les génériques !!!
Posté par Christophe --- . En réponse à la dépêche Astérix et Obélix : Mission Cléopâtre. Évalué à 1.
Bon, pour ceux qui aiment bien les génériques, je vous recommande celui de Serial Lover, il est à l'image du film : excellent.
(-1, car je tend un peut vers le HS là, quand même, hein...)
[^] # Re: Pas assez puissant...
Posté par Christophe --- . En réponse à la dépêche Une distribution, une autre. Catégorie : mini.. Évalué à 10.
Depuis quand n'y aurait-il pas de solution pour toi, avec linux ? :)
Je te propose ceci :
http://elks.sourceforge.net/(...)
Il s'agit d'ELKS, The Embeddable Linux Kernel Subset. Je te laisse le soin de consulter la page pour les informations détaillées. Il s'agit d'un dévellopement de Linux pour les systèmes à base de 8086 et 80286. Je ne sait pas si tu trouvera ton bonheur la-dedans, mais en tout cas tu pourra t'amuser avec :-)
[^] # 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.