Tout est dans le titre :D
vendredi 2 janvier 2009
Bonne année
Par Mjules le vendredi 2 janvier 2009, 21:22
Aller au contenu | Aller au menu | Aller à la recherche
vendredi 2 janvier 2009
Par Mjules le vendredi 2 janvier 2009, 21:22
Tout est dans le titre :D
lundi 1 septembre 2008
Par Mjules le lundi 1 septembre 2008, 22:13
Ce matin, je me suis dit que tant qu'à changer d'hébergeur, autant en profiter pour changer d'autres trucs ;). J'ai donc mis à jour ce blog vers dotclear 2. Normalement, il ne devrait pas trop y avoir de casse, sauf pour les fils RSS et commentaires auxquels il faut se réinscrire, le format ayant totalement changé.
N'hésitez pas à me laisser un commentaire si vous constatez un problème.
dimanche 31 août 2008
Par Mjules le dimanche 31 août 2008, 23:07
Suite à un comportement très bizarre de mon hébergeur (pages persos free.fr), j'ai du me résoudre à déplacer ce blog. La nouvelle adresse est donc
http://mjules.littleboboy.net/carnet.
Je vous invite à mettre à jour vos marques-pages et abonnements RSS/atom. Il y a une redirection vers le nouveau site mais il n'y a aucune garantie qu'elle persiste dans le temps :).
En attendant, un grand merci à mon nouvel hébergeur qui m'a gentiment fait une place ici :).
mercredi 21 novembre 2007
Par Mjules le mercredi 21 novembre 2007, 19:08
En 2006, j'avais écrit un petit tutorial sur la façon de gérer les nombreux boutons de ma MX1000 sous Xorg (GNU/linux), depuis, ça a un peu évolué et ça s'est encore simplifié :
Section "InputDevice" Identifier "MX1000" Driver "evdev" Option "Name" "Logitech USB Receiver" Option "CorePointer" EndSectionEn clair, la souris est appelée par son nom et pas par son periphérique, il est possible bien que peu probable qu'il y ait des conflits de nom, dans ce cas, vous pourriez utiliser l'option Phys ou Device pour désigner la souris, voir le man d'evdev pour plus d'info.
Cette conf est bien évidemment utilisable moyennant quelques modifications avec d'autres souris boutonneuses (MX700, MX400 etc).
P.S. : ceci doit fonctionner depuis xorg 7.0 mais je n'ai pas testé, utilisant un Xorg 7.2
dimanche 16 septembre 2007
Par Mjules le dimanche 16 septembre 2007, 21:04
Ces derniers temps, j'avais envie de lire un peu de fantaisie et pas trop envie de chercher un nouvel auteur. Je me suis donc lancé dans la lecture du cycle des Rêveurs (Le réveils des anciens Dieux, La dame d'atout, Les Gorges de cristal, La folie des dieux) de David et Leigh Eddings. Ayant découvert et apprécié ces auteurs avec la rédemption d'Althalus, j'avais ensuite dévoré la Belgariade, la Mallorée et les préquelles. Bref, je m'attendais à passer un bon moment.
Et bien, c'est raté ! Le moment, et les bouquins. Autant être clair, pas la peine de dépenser votre argent dans ce cycle, il ne vaut pas grand chose. L'histoire aurait pu être intéressante mais on se lasse très vite des X narrations de la même scène par des points de vues différents, du développement/remplissage sur 3 chapitres de la vie d'un personnage secondaire (et il y a beaucoup de personnages secondaires...) qui n'apporte absolument rien à l'histoire, un Deus ex Machina qui pulvérise la cohérence de l'histoire dès le tome 2 et rend la fin absolument minable, j'ai pourtant une tolérance au TGCM (Ta Gueule C'est Magique) assez élevée ; sans compter une traduction très moyenne et mal relue (erreur dans les noms, fautes d'orthographes etc).
Bref, j'ai beau être bon public, je ne peux que vous déconseiller ces livres. Ne vous fiez pas aux auteurs, ils ont écrit de très bons livres mais ceux là n'en font vraiment pas partie.
dimanche 2 septembre 2007
Par Mjules le dimanche 2 septembre 2007, 16:09
Depuis que je suis chez Orange, j'ai remarqué que le téléchargement de fichiers depuis les pages perso de free est lent.
Plus exactement, il semble limité aux alentours de 30ko/sec. Après quelques investigations voilà ce que j'ai pu constater :
Bref, il me semble bien qu'il y a effectivement une limitation mis en place dans le cas présent. La question maintenant est qui bride qui ? Est ce Orange qui limite l'accès vers les pages persos free (rétorsion commerciale ?) ou est ce free qui limite l'accès depuis les abonnées Orange. Honnêtement, la première possibilité me parait la plus probable, la deuxième n'ayant qu'un intérêt limité pour free.
Si vous avez des informations plus précises ou un avis sur la question, je suis preneur, n'hésitez donc pas à « lâcher vos com' ! ».
lundi 30 juillet 2007
Par Mjules le lundi 30 juillet 2007, 20:17
Le zoo d'Amiens est plein de surprise, je ne m'attendais pas à y trouver ce petit animal, que j'ai plutôt tendance à utiliser pour naviguer sur internet :
mercredi 23 mai 2007
Par Mjules le mercredi 23 mai 2007, 19:03
Enfin de retour après une longue absence due à mon déménagement et à l'incapacité de certains opérateurs ADSL à me reconnecter. Normalement, je vous en dirai plus très bientôt.
jeudi 29 mars 2007
Par Mjules le jeudi 29 mars 2007, 20:36
Une image amusante sur la différence fondamentale entre la science et la foi. (source HFR)
lundi 12 mars 2007
Par Mjules le lundi 12 mars 2007, 19:40
Deux grandes élections approchant, je me devais de parler un peu de ce problème qu'est le vote électronique.
Le vote électronique est un problème car il interdit toute vérification au préalable de la machine (est elle conforme, est elle bien « vide » de tous bulletins ?) et par la suite interdit tout recomptage des bulletins.
En effet, si il est simple de voir dans une urne transparente son bulletin tomber, il est ardu pour ne pas dire impossible d'être certains que son vote a été comptabilisé par la machine.
Bref, on ajoute des possibilités de fraudes (à grande échelle et très simplement, qui peut vérifier le programme des machines dans chaque bureau de vote ?) sans aucunement limiter les fraudes existantes (les faux électeurs ne seront pas plus facilement démasqués). Pour ma part, je fais mien des mots d'autres et j'appelle ça un recul démocratique.
Vous n'êtes bien sur pas obligé de me croire sur parole et je vous invite à lire les liens suivants :
Le site de padawan qui nous alerte depuis 2004
Ordinateur de vote.org (anciennement recul-democratique.org) mine d'information sur le sujet même si le site n'est pas très beau
Lettre ouverte à André Santini, député-maire d'Issy-les-moulineaux
Et enfin, la pétition pour le maintien du vote papier :
dimanche 3 décembre 2006
Par Mjules le dimanche 3 décembre 2006, 15:01
Il y a de ça deux ans, j'avais écrit un billet répertoriant ce qui manquait et portant le même titre : ce qui me manque sous GNU/linux. 2 ans ce sont écoulés, il est temps de faire le bilan et de reprendre les points que j'avais alors évoqué.
AU final, en 2 ans, pas mal de choses ont évolué et même si ce n'est pas encore parfait, l'avenir ne s'annonce pas si mal que ça.
jeudi 16 novembre 2006
Par Mjules le jeudi 16 novembre 2006, 21:08
Cet article est basé sur ce que je comprend du fonctionnement de X11. Il est loin d'être parfait et comporte peut-être des erreurs. si c'est le cas, j'apprécierais qu'on me les signale pour pouvoir améliorer le tout.
Plus grand chose en fait, nous avons vu à peu près les grands principes de fonctionnement de X11 et des dernières technologies développées autour. Il y a seulement 1 an, beaucoup de monde râlait et pestait contre Xorg et sa gestion antédiluvienne des fenêtres par rapport à des OS comme MacOS X ou même XP.
1 an plus tard, on peut dire sans trop de complexe que La couche graphique X11 n'a pas grand chose a envier aux derniers développements des OS propriétaires. Il reste encore beaucoup à faire et à inventer pour amener le plein potentiel de ces technologies mais elles sont là et elles marchent.
Il reste néanmoins quelques problèmes à régler :
J'espère que ça vous (les lecteurs) a plus, que ça vous a un peu éclairé et que je n'ai pas dit trop de bêtises (je ne pense pas mais sait on jamais).
Quant à moi, j'ai bien aimé Inkscape, c'est vraiment sympa à utiliser, surtout la dernière version que je trouve nettement plus ergonomique que la précédente.
mercredi 15 novembre 2006
Par Mjules le mercredi 15 novembre 2006, 19:30
Cet article est basé sur ce que je comprend du fonctionnement de X11. Il est loin d'être parfait et comporte peut-être des erreurs. si c'est le cas, j'apprécierais qu'on me les signale pour pouvoir améliorer le tout.
dans l'article précédent, nous avons aperçu le fonctionnement de XGL qui est l'une des solutions proposée pour accélerer le rendu en utilisant la partie 3D de la carte graphique. A peu près au même moment, RedHat a développé une autre solution pour cette problématique, AIGLX, acronyme qui signifie Accélérated Indirect GL X.
AIGLX est basé sur un principe complètement différent de XGL. Plutôt que de réinventer un serveur X, les développeurs ont préféré modifier celui existant pour lui permettre d'accélérer certaines opérations particulières à l'aide de la partie 3D de la carte graphique.
Ici, le gestionnaire de composition va s'adresser à la libGL en lui envoyant une instruction spéciale : GL_EXT_texture_from_pixmap. La libGL va alors transmettre cette instruction et ce qui va avec au serveur X par le biais de l'extension GLX. Le serveur X, quant à lui, va relayer le tout vers la partie 3D de la carte graphique.
On est donc bien en face d'un rendu 3D indirect qui passe par le serveur X, la différence avec le rendu indirect "classique" c'est que maintenant, celui-ci est accéléré par la carte 3D et profite de sa puissance.
La gestion de la composition implique certes des aller-retours entre le gestionnaire de composition et le serveur X mais quelques optimisations du protocole permettent d'éviter que cela surcharge trop le système : les manipulations avant le rendu sont effectuées par le serveur X sur ordre du gestionnaire de composition, ainsi, seule les informations de manipulations sont à transmettre, les données ne sont transmises qu'une seule foi.
Les avantages de ce modèles, c'est que le rendu direct est toujours possible pour les applications qui le demandent. L'autre avantage, c'est que d'après la théorie, la transparence réseau est toujours là y compris lorsque l'on utilise la composition.
Le défaut, c'est que contrairement à XGL, ici seule certaines opérations sont accélérées, le reste des opérations continue à utiliser le schéma 2D classique.
Au contraire de XGL, le développement d'AIGLX s'est fait de manière totalement ouverte et AIGLX a été inclu dans Xorg 7.1.
dimanche 12 novembre 2006
Par Mjules le dimanche 12 novembre 2006, 17:27
Cet article est basé sur ce que je comprend du fonctionnement de X11. Il est loin d'être parfait et comporte peut-être des erreurs. si c'est le cas, j'apprécierais qu'on me les signale pour pouvoir améliorer le tout.
Dans les billets précédents, on a vu comment Xorg se débrouillait pour afficher des choses sur l'écran en 2D et en 3D. Ça fonctionne très bien mais ce mode de fonctionnement comporte des limitations qui rendent difficile l'évolution de l'affichage. En particulier, avec ce mode de fonctionnement, il est très complexe de faire des choses comme des ombres derrières les fenêtres, ou tout bonnement des fenêtres transparentes. C'est pourquoi le protocole X11 a été encore étendu avec l'extension Composite. Celle-ci va permettre de modifier le comportement du rendu. En effet, au lieu que le serveur envoie directement les informations sur chaque fenêtre à la carte graphique ; celles-ci sont envoyées dans un espace de la mémoire où elles peuvent être ensuite manipulées par un gestionnaire de composition avant que le résultat soit rendu par la carte graphique.
L'énorme avantage, c'est qu'avec cette méthode, il devient très simple de faire, par exemple, une fenêtre réellement transparente. Le gestionnaire de composition possédant toutes les infos pour celà (il sait exactement quelle fenêtre est au dessus de quelle autres etc).
L'énorme inconvénient, c'est que ça nécessite beaucoup de puissance graphique et donc, pour pouvoir faire ça sans que l'affichage rame atrocement, il faut de l'accélération par la carte graphique.
Cette accélération est disponible avec la partie 2D de la carte via les extensions XAA ou plus récemment EXA. Néanmoins, l'accélération 2D pose quelques problèmes qui rendent son utilisation peu intéressante :
Bref, la conclusion s'imposait d'elle même, il fallait trouver un moyen d'accélerer tout ça en utilisant la partie 3D de la carte graphique.
2 solutions ont alors été développées qui répondent à cette problématique : XGL par Novell/Suse et AIGLX par Fedora/RedHat.
XGL a été la première solution présentée par Novell au tout début de l'année 2006. Son développement a fait l'objet de quelques critiques, en effet, il a principalement été réalisé de manière non-ouverte. Les craintes quand a la fermeture du projet ou du code ont depuis été levées.
Le schéma de principe :
Le schéma ci-dessus présente XGL dans son implémentation Xglx, c'est à dire utilisant 2 serveurs X. Il existe une autre implémentation, Xegl, encore à l'état de projet, qui se baserait sur les EGL, des bibliothèques openGL censées parler directement à la carte graphique.
Comme on le voit sur le schéma, Xgl va donc jouer un double rôle, il est simultanément un client X pour les applications et un serveur X utilisant openGL. Au démarrage, Il va dialoguer avec libGL (et donc le serveur X sous-jacent) et obtenir un rendu 3D direct. Ainsi, toutes les opérations du serveur XGL sont susceptibles d'être accélérées par la carte graphique et en particulier par sa partie 3D. En particulier, toutes les opérations d'un gestionnaire de composition (compiz, beryl par exemple) seront accélérées du moment que celui-ci utilise openGL.
Cela fonctionne très bien mais à quand même quelques défauts relativement gênant : comme pour tout rendu direct, on dit au revoir à la transparence réseau ; la nécessité d'avoir 2 serveurs X tournant simultanément augmente la mémoire occupée ainsi que la complexité du système ; enfin, et c'est le plus gênant, il est impossible pour les autres applications 3D (les jeux par exemple) d'obtenir un rendu direct vers la carte graphique. Elles n'obtiennent au mieux qu'un rendu indirect par le serveur XGL, ce qui pose un problème de performance.
Les 2 derniers problèmes sont liés à l'implémentation Xglx et devrait disparaitre avec Xegl. Mais cette dernière n'est encore que théorique.
vendredi 10 novembre 2006
Par Mjules le vendredi 10 novembre 2006, 17:43
Cet article est basé sur ce que je comprend du fonctionnement de X11. Il est loin d'être parfait et comporte peut-être des erreurs. si c'est le cas, j'apprécierais qu'on me les signale pour pouvoir améliorer le tout.
Dans les articles précédents, nous avons parlé du rendu 2D et d'une des méthode de rendu 3D, le rendu direct qui nécessite un accès direct à la carte graphique. Aujourd'hui nous allons parler de l'autre méthode utilisée pour le rendu 3D, le rendu indirect.
Le schéma qui va bien :
Comme on peut le voir, le rendu 3D indirect est un peu différent. Il fait intervenir une extension du protocole X11 appelée GLX, c'est elle qui va permettre au serveur X de gérer les commandes openGL.
Reprenons donc le cheminement. Une application 3D programmée en openGL va donc s'adresser à la libGL, celle-ci pour une raison ou un autre ne peut pas ouvrir un accès direct à la carte et elle va alors s'adresser à l'extension GLX au niveau du client X. Les commandes openGL vont alors transiter comme les commandes classiques 2D entre le client et le serveur X. Enfin, le serveur X va réaliser l'opération de rendu et envoyer les infos à la carte graphique pour qu'elle affiche ce qu'il faut à l'écran.
On voit donc ici que le rendu final est effectué au niveau du serveur X et pas directement par la carte graphique, d'où le nom de rendu indirect.
Ceci va avoir quelques avantages : on retrouve la transparence réseau, les commandes passant par le chemin classique de X. L'autre avantage, c'est qu'on ne dépend que de la libGL (qui est intriquée avec GLX) pour interpréter les commandes openGL et non d'une implémentation matérielle d'openGL dans la carte graphique.
A l'opposée, le rendu indirect a un énorme défaut, c'est qu'avec les serveurs X inférieurs à Xorg 7.1, le rendu est intégralement effectué au niveau du serveur par le processeur central de la machine. Et le CPU, il aime pas du tout ça parce qu'il n'est pas fait pour. Résultat, c'est effroyablement lent (facilement d'un facteur 20 par rapport au rendu direct).
jeudi 9 novembre 2006
Par Mjules le jeudi 9 novembre 2006, 21:00
Cet article est basé sur ce que je comprend du fonctionnement de X11. Il est loin d'être parfait et comporte peut-être des erreurs. si c'est le cas, j'apprécierais qu'on me les signale pour pouvoir améliorer le tout.
Nous avons vu dans la première partie, l'architecture client/serveur du système X11. Evidemment, il n'a pas échappé à votre oeil de lynx que le schéma ne mentionnait que la 2D et ne faisait qu'une vague référence à la 3D. C'est tout à fait normal, au moment où X11 a été inventé (vers 1984), la 3D n'était pas particulièrement développé et l'architecture n'en a pas forcément tenu compte d'emblée.
Heureusement pour nous, cette lacune a été comblée depuis et X peut maintenant gérer la 3D. C'est ce que nous allons voir maintenant (tout au moins une partie).
Avec X, la gestion de la 3D au niveau des applications repose sur une API (interface de programmation) assez connue nommée OpenGL. Cette API offre aux application un ensemble de fonctions qui permettent de dessiner en 3D (Direct3D fait de même sous MS-Windows).
Sous GNU/linux (et les autres), c'est le projet Mesa3D qui implémente OpenGL et founis la bibliothèque qui va bien aux applications, la libGL.
A ce stade, on est encore au niveau de l'application et pas encore de la carte graphique, et le problème, c'est que celle-ci ne comprend pas directement l'OpenGL. On va donc avoir forcément une transformation quelque part. C'est ce qu'on appellera le rendu 3D et suivant la méthode il pourra être direct ou indirect.
Il est représenté dans le schéma ci-dessus. Dans le rendu direct, l'application 3D va s'adresser à la libGL pour son affichage. La libGL va alors communiquer directement avec le serveur X, demander et obtenir l'autorisation d'accéder à la partie 3D de la carte graphique.
Une fois le droit d'accès donné, la libGL va convertir les commandes OpenGL en commandes compréhensibles par la carte et les envoyer directement à la carte 3D. Ces 2 dernières étapes mettent en jeu le pilote 3D lequel est fortement intriqué avec la libGL.
Dit comme ça, on voit pas trop l'intérêt ; mais en réalité, celà signifie que le traitement 3D est directement effectué par la carte (d'où son nom ), aucun passage par le serveur X et donc nettement moins de traitement au niveau du CPU. On a donc une accélération 3D complète de l'application.
L'inconvénient majeur de cette méthode, c'est qu'il faut dire au revoir à la transparence réseau, en effet, l'application accède à la libGL au niveau client X et cette dernière accède directement au matériel ; il est donc impossible d'avoir de l'affichage déporté avec cette méthode.
Pendant ce temps là, les applis non-3D continuent bien sur à utiliser le rendu 2D classique que nous avons déjà vu.
mercredi 8 novembre 2006
Par Mjules le mercredi 8 novembre 2006, 19:38
Il y a des moments où on a pas envie de faire des trucs constructifs (i.e. mes sujets pour l'exam de chimie par exemple). hier, Je me suis donc mis à tester inkscape. Et histoire de pas faire ça dans le vide et de me clarifier certains points, j'ai donc décidé de schématiser le fonctionnement de X11.
Cet article est basé sur ce que je comprend du fonctionnement de X11. Il est loin d'être parfait et comporte peut-être des erreurs. si c'est le cas, j'apprécierais qu'on me les signale pour pouvoir améliorer le tout.
Pour ceux qui ne le sauraient pas, X11 est le protocole qui est implémenté par xorg, le truc qui s'occupe de faire un bel affichage graphique sous les différents *nix modernes (linux, et BSD surtout). Son fonctionnement est un peu compliqué et je vais donc vous le détailler dans un schéma réalisé avec inkscape (cliquer pour la version plus grande, le svg est dispos sur demande).
X11 fonctionne sur le modèle client/serveur, on a donc d'un côté le client X (la xlib ou plus récemment, xcb) qui parle aux applications et au serveur X et d'un autre côté, le serveur X qui parle au matériel et au client X.
Suivons un peu le cheminement de tout ça. Imaginons que je vienne d'ouvrir openoffice writer et que je veuille taper du texte. La fenêtre d'openoffice est affichée sur mon écran par ma carte graphique. Celle-ci a reçu les infos du serveur X qui s'est adressé à sa partie 2D par le biais du pilote DDX.
J'appuie sur une touche (A). Le serveur X reçoit l'information comme quoi j'ai tapé sur la touche A, il va alors transmettre cette information au client X, celui-ci va alors la faire parvenir à openoffice.
Openoffice réagit et commande alors l'affichage de la lettre A sur la partie qu'elle destine à l'écriture. Elle envoie alors cette information au client X qui la transmet au serveur X. Le serveur X reçoit la commande et la converti en une commande compréhensible par la carte graphique grâce à son pilote.
La carte graphique trace la lettre et l'affiche sur l'écran.
C'est vrai que dit comme ça, ça peut sembler un peu usine à gaz. Mais il y a quand même un énorme avantage dans cette organisation ; le client et le serveur n'ont absolument pas besoin d'être sur la même machine ! En conséquence, il devient très simple d'avoir une machine puissante qui ne comporte que le client X (le serveur d'application) et une ou plusieurs machine peu puissante qui ne possède que le serveur X (le client d'application) et utilisent les applications sur le serveur d'applications. On fait ainsi simplement de l'affichage déporté.
Bien sur, ce que j'ai écris au dessus n'est qu'un aperçu du fonctionnement du protocole X11, j'ai passé sous silence les toolkits graphiques qui sont des bibliothèques d'objets qui évitent à chaque application de réinventer la roue pour faire du graphique, j'ai également omis de parler des polices et du rendu côté serveur de celles-ci ainsi que de plein d'autres trucs (les window manager par ex).
Si je suis pas trop feignasse, je devrais d'ici peu palier un peu ces manques en vous parlant du rendu direct, du rendu indirect, de XGL et si j'arrive à comprendre correctement de AIGLX et de Glucose. Avec bien sur quelques schémas à la clé ; parce que inkscape, c'est bien :D
vendredi 20 octobre 2006
Par Mjules le vendredi 20 octobre 2006, 19:17
Aujourd'hui présentation d'un soft que j'ai découvert il y a quelques semaines et qui remplace très facilement et très agréablement le vénérable top, utilitaire de visualisation des process tournant sur la machine : htop
Quelques avantages :
Bref, un soft que je ne regrette vraiment pas d'avoir installé pour remplacer top
mercredi 27 septembre 2006
Par Mjules le mercredi 27 septembre 2006, 20:54
En voilà une phrase qu'on entend périodiquement aussi bien chez les pro-linux que chez les anti. A force, en lisant les moultes démonstrations, on finirait presque par croire que c'est vrai. Il y a juste un petit détail qui me chagrine à chaque fois...
C'est quoi le "desktop" ? Parce que de la réponse à cette question dépend la réalité de l'assertion en titre.
Et c'est là que je suis rarement d'accord avec l'auteur du moment, à chaque fois, il part du principe que le système doit s'installer sans douleur, se configurer quasi-magiquement (pilote et réglages) et ...
Et rien en fait, la plupart du temps, la démonstration s'arrête à ces 2 points et ne parle absolument pas de la suite, l'utilisation.
Mais franchement, quel OS peut se targuer de réussir les 2 points de la démonstration ? windows ? pas vraiment, la configuration par défaut de windows est atroce une fois sur 2 (le 60Hz sur un écran qui supporte le 100 sans broncher, j'ai toujours apprécié) et l'installation est pas vraiment simple (l'obligation d'installer chaque soft un par un est assez énervante, sans compter qu'il faut parfois redémarrer, pourquoi faire d'ailleurs ?) ; linux fait un peu mieux sur l'install, nettement mieux sur la configuration mais pêche dès qu'un pilote n'est pas inclus par défaut, ça a beau être de la mauvaise volonté des constructeur, c'est quand même très agaçant voire bloquant.
Résultat ? pour moi c'est sur, linux (comme windows d'ailleurs) n'est pas près pour ce desktop là.
Maintenant, considérons une autre définition que, pour ma part, je préfère : un desktop, c'est une machine qui permet de réaliser les tâches courantes que je veux réaliser : de la bureautique (texte, tableaux, présentations), du surf, mes mails, ma messagerie instantanée, suivre l'actualité, retoucher quelques images et les imprimer, jouer un peu, faire mes comptes, écouter de la musique, lire des videos ; j'ai à peu près fais le tour.
A l'exception peut-être des jeux commerciaux qui ne sont pas portés sous linux (et encore, il y a une tripotée de jeux natifs, commerciaux ou non), je peux faire tout ça indifféremment avec n'importe quel OS. Et en particulier, puisque c'est le propos qui nous intéresse, je peux faire tout ça sous GNU/linux
Pour finir parce que c'est déjà bien long, Effectivement GNU/linux n'est pas près pour le desktop si on ne considère que sa gestion du matériel (mais franchement, windows ne fait pas beaucoup mieux). Par contre, dès qu'on regarde l'utilisation de tous les jours, là, force est de constater que GNU/linux est déjà sur le desktop. Si il est prêt ou non est pour moi un combat d'arrière-garde.
PS : j'utilise volontairement linux dans la première partie car GNU/linux est rarement employé dans cette situation
PPS : je ne parle pas de MacOS X que je ne connais pas assez
jeudi 24 août 2006
Par Mjules le jeudi 24 août 2006, 19:02
C'est officiel depuis cet après midi, le dieu romain des enfers ne fait plus partie des grands de ce système.
L'Union Astronomique Internationale a donc décidé, par un vote à main levé, de redéfinir les objets célestes en planètes, planètes naines et petits corps du système solaire.
Pluton, découverte en 1930, n'aura donc même pas eu le temps de faire une révolution complète autour du soleil (248 ans) avant de se retrouver reléguée dans la deuxième catégorie et de disparaitre de la liste des planètes du système solaire (Mercure, Vénus, La Terre, Mars, Jupiter, Saturne, Uranus, Neptune). Neptune devient donc la planète la plus éloigné du soleil, ce qu'elle était déjà temporairement en raison de l'excentricité de l'orbite de Pluton.
la page de wikipedia sur le sujet est déjà à jour.
« billets précédents - page 1 de 3