Tu parles de complexité dans le pire cas, et là, tu as raison.
Maintenant, c'est un fait que le fait de programmer dans un langage de haut niveau permet souvent d'écrire des algos avec une meilleure complexité moyenne.
C'est ce que j'explique toujours aux gens qui pensent que l'assembleur est le meilleur langage pour faire du code efficace : Avec une main d'oeuvre réduite, c'est souvent faux. Si tu me donnes 5 minutes pour faire un tri de tableau, si je le fais en C, je vais faire un quicksort (n.log(n) en moyenne, n^2 dans le pire cas), en assembleur, je vais faire un tri par insertion (n^2), et en C++, je vais utiliser la STL qui a déjà tout fait pour moi (Un mélange de quicksort, de tri fusion et de tri par insertion si mes souvenirs sont bons. l.log(n) dans tous les cas.). D'ailleurs, en C++, il me reste 4minutes30 pour aller prendre un café ;-)
Je ne parle même pas de table de hash, de pattern-matching d'expressions régulières ou autres algos un minimum compliqués !
> Tester une série d'opération arithmétique n'est pas intéressant (ça donne si les test sont
> bien fait, les mêmes résultat,
Ben ça sert à quoi alors de compiler avec -O3 ?
Bon, quand on dit qu'on benchmark un langage, en fait, c'est clair qu'on benchmark un compilateur et l'environnement d'execution, mais bon.
Tu écrit
x = y + z;
t = x + w;
a = b + c;
Maintenant, tu as
Déjà pour un langage interprêté, pour faire y + z, il faut faire un switch sur l'opérateur (voire un appel de fonction), voir que c'est un "+", puis l'executer. Donc, si tu as les mêmes performances en lisp interprêté et en C, y'a de quoi se poser des questions.
Ensuite, est-ce que y et z sont passés par valeur ou par référence. En Java, si x et z sont des "Integer", il faut deux indirections de pointeurs. Ca coûte cher !
En Ada, y + z fait un test de débordement et lève potentiellement une exception (sauf si tu l'as désactivé à la compilation), pas en C.
Maintenant, entre deux compilateurs C.
Tu as celui qui a géré n'importe comment ses registres, qui a mis y et z dans la mémoire, et puis celui qui a mieux optimisé ses registres, et qui a déjà y et z dans des registres. Hop, on économise deux instructions "load".
Ensuite, tu as le compilateur con qui compile tout ça dans l'ordre, et qui est obligé d'attendre que x = y + z; soit fini pour commencer t = x + w; et celui qui a remarqué qu'en executant à la place
x = y + z;
a = b + c;
t = x + w;
On avait la même sémantique, mais qu'on utilisait mieux le pipelining du processeur. Et oui, le même ensemble d'instructions assembleurs ne s'executent pas à la même vitesse selon l'ordre dans lequel elles passent. Fait du pas à pas avec gdb dans du code compilé avec "-g -O3", tu verras que le curseur revient parfois en arrière.
Maintenant, tu as raison sur le fait qu'il y a bien d'autre choses à benchmarker. (les parcours de tableaux par exemple, c'est un cas d'école en matière de compilateur optimiseur).
Rappelons qu'une source d'énergie intéressante est aussi le bois.
On fait de la fusion nucléaire sur le soleil, qui a la bonne idée de nous en envoyer le résultat sous une forme pas trop nocive. (lumière)
On fait capter cette lumière par des arbres.
On coupe les arbres, et on en replante.
On brule le bois qu'on a coupé
On récupère l'énergie dégagée
Les arbres recoupés récupèrent le CO2 dégagé.
C'est con, mais les hommes préhistoriques faisaient comme ça et ils avaient bien raison (sauf qu'au lieu de planter, ils attendaient que ça repousse !)
Il faut diviser par deux pour enlever la nuit, et encore par deux pour prendre l'intégrale sur une journée.
Il reste 300 W/m^2.
Ensuite, tout est question de rendement. Pour l'instant, on a des rendement dégueulasses (si mes souvenirs sont bons, de l'ordre du %). Si la recherche avance à ce niveau là, qu'on arrive à faire mieux et pas trop cher, tu remplaces les tuiles de ton toit par des panneaux solaires et ça alimente ta maison. (100m^2 * 30W/m^2 = 3Kwatts, c'est très raisonnable).
Pour l'instant, on peut alimenter sa maison en faisant comme ça si on économise l'électricité au max (Je connaissais quelqu'un qui avait fait ça a une époque, il revendait le surplus à EDF ou consommait quand il n'y avait pas de soleil, il était à peu près équilibré.). Mais bon, c'est pas tout rose non plus : lampes à économies d'énergie : visiblement c'est un bon truc niveau écologie, mais il y a quand même du mercure dedans, chauffage/cuisine au gaz : rejet de gaz à effets de serre, etc ...
La question est : Si on avait mis les thunes qu'on a mis dans le nucléaire pour le solaire et réciproquement, où en serait-on ?
Ou bien de l'hydro-electricité comme ça se fait déjà.
Parce que : SCOOP : Les centrales nucléaires non plus, on ne les éteint pas la nuit !
Donc, on utilise les barrages pour réguler la quantité d'énergie à court terme (journée) et à échelle d'une saison (les barrages sont vides à la fin de l'hivers en général). Soit on les arrête la nuit, soit carrément, comme à grand-maison au dessus de Grenoble, on pompe à l'envers la nuit.
GNOME et Kde, c'est d'abord des bibliothèques pour les applications. On peut citer la boite de dialogue toute faite pour l'impression, et la gestion des composants graphiques (bobono, kparts) en plus dans ta liste.
Expérience : désinstalle Gnome et/ou Kde de ta machine, et regarde ce qui reste.
Rien ne t'oblige à utilser Gnome/Kde en temps que bureau, mais que les applications que tu utilise fassent elles-même appel à eux, c'est important.
Mettons que tu commence par sauver une table de inodes au début de /dev/hda, ton 'dd' continue à gratter, pendant ce temps, un utilisateur fait un 'rm toto'. Quand le dd arrive sur l'emplacement physique de toto, le fichier a été effacé, potentiellement écrasé, mais ta table de inodes sauvegardée pointe toujours dessus.
bon, le "init 1" te sauve, là, mais encore, ton kernel peut très bien décider de flusher son cache au milieu, ou une connerie du genre, et là, ...
Bref, ça marche "bien" sur des machines pas chargées, mais je déconseille fortement ce genre de truc sur un serveur chargé.
OOo est lourd en partie *a cause* de la couche suplémentaire qu'il a et qui de base est assez merdique (déjà pas mal améliorée dans la 1.1). En passant par de vrais toolkits (Gtk/Qt), il y a pas mal de chance que ça s'améliore grandement.
Les gens qui voudront un truc rapide feront du Gtk natif, ceux qui seront prets a sacrifier un peu pourront faire du Gtk-Qt. Mais le "un peu" sacrifié, ce n'est que pour le dessin des widgets, donc, par exemple, pas pour le boot.
Ben maintenant, essaye de faire une couverture de magazine avec xfig qu'on rigole. Je veux dire un truc avec plus que les 32 couleurs que xfig gère, des dégradés, éventuellement de la transparence, tout ça, quoi ...
Quelle est la proportion de la surface d'écran utilisée par Gimp ? Pas beaucoup. Avec ce méli-mélo, tu as le choix entre des fenêtres qui se superposent (pratique, la boite d'outils par dessus ton image ! Il faut la déplacer à chaque fois que tu veux travailler sur l'endroit qui est en dessous ...), ou beaucoup d'espace inutilisés entre les fenêtres (sur les screenshots, on voit en général plus le fond d'écran que Gimp lui-même.)
Sans aller jusqu'aux fenêtres dans les fenêtres, la possibilité d'avoir des tabs avec plusieurs images groupées serait déjà pas mal. (Tout le monde n'utilise pas pwm ...) La possibilité de docker les boites de dialogue dans la 2.0 est un grand pas en avant à ce niveau là.
Sinon, pour le bouton droit de la souris sous Mac, moi, les mac-eux que je connais, une fois qu'ils ont touché à Windows, ils regrettent de ne pas l'avoir (idem pour la molette ...)
Gegl -- Generic Graphical Library --- is an image processing library based on GObjects.
En gros, l'idée est de mettre toutes les fonctions de traitement d'image dans une librairie bien propre, et Gimp serait plus ou moins un front-end à tout ça.
C'est à mon avis une *excellente* nouvelle : De la même manière que Gimp a crée son propre toolkit (Gtk, à la base, c'est Gimp ToolKit), qui a été réutilisé et amélioré par plein d'autres applications, on peut espérer voir naitre un projet similaire à Gimp pour KDE par exemple, avec une autre interface, mais des fonctionalités similaires, les progrès de l'un bénéficiant à l'autre.
> Ils ont enfin fait des évolutions de l'interface
Oui !
> pour avoir qulque chose d'utilisable
Prèsque !
Les changements les plus visibles : Il y a un menu horizontal en haut de la fenêtre dessin. (Les sous menus étaient très chiants à atteindre à la souris).
Une vision assez sympa pour regrouper la multitude de petites boites de dialogues qui trainaient partout : On peut avoir plusieurs boites de dialogues dans une fenêtre avec des tabs, et en plus, on peut couper les fenêtres en deux horizontalement. Bref, ils ont ajouté les fonctionalités intéressantes de ion, quoi ;-)
Le truc que je trouve dommage : visiblement, on ne peut pas utiliser tout ça avec les fenêtres qui contiennent les images. Là, c'est encore une fenêtre du window manager par image.
>> La disponibilité des spécifications d'interface d'Office 11 est un pré-requis pour
>> la prise en compte dans une version ultérieure du CCI."
[...]
> Ils ont intérêt à vraiment l'ouvrir leur format 8-)
"Microsoft rend disponible les schémas de référence XML d'Office 2003"
Tu disais ?
(D'ailleurs, c'est pas un hasard que tout ça se passe en même temps. MS a bien compris qu'ils perdraient le marché des administration puis petit à petit bien d'autres si ils n'ouvraient pas leurs formats ...)
(Par contre, ce qui est crétin, c'est que quand tu va télécharger leur truc, c'est un fichier .exe -- Faut pas abuser des bonnes choses !)
Pour l'utilisateur de Windows "de base", le bouton du milieu, c'est le "bonton internet", ou quelque chose du genre. Et c'est vrai, il l'a lu dans le catalogue carrefour, alors, ...
"Il y a un an, j'ai supprimé définitivement ma partition Windows [...], à part pour jouer, ça fait des années que Windows ne me servait vraiment plus à rien."
[^] # Re: Comparaison de neuf langages sur un micro-benchmark
Posté par Matthieu Moy (site web personnel) . En réponse à la dépêche Comparaison de neuf langages sur un micro-benchmark. Évalué à 3.
> A demander à ton compilo de compiler correctement...
Ben c'est toi, deux commentaire plus haut, qui me disait que pour des opérations arithmétiques, le temps d'execution devait toujours être le même.
Si tu as une option pour optimiser, c'est bien qu'il est possible de faire des choses différentes pendant la compilation.
[^] # Re: Comparaison de neuf langages sur un micro-benchmark
Posté par Matthieu Moy (site web personnel) . En réponse à la dépêche Comparaison de neuf langages sur un micro-benchmark. Évalué à -1.
> spécifiques à windows...
Si tu parles de .NET, tu as sans doute du passer à coté de mono qui en est une implémentation sous Linux.
[^] # Re: Comparaison de neuf langages sur un micro-benchmark
Posté par Matthieu Moy (site web personnel) . En réponse à la dépêche Comparaison de neuf langages sur un micro-benchmark. Évalué à 0.
Oui, mais là, on mesure la vitesse du code produit, pas la vitesse de compilation.
Et l'auteur précise bien qu'il execute le binaire en windows hors cygwin.
[^] # Re: Comparaison de neuf langages sur un micro-benchmark
Posté par Matthieu Moy (site web personnel) . En réponse à la dépêche Comparaison de neuf langages sur un micro-benchmark. Évalué à 3.
C'est surtout l'implémentation, mais le langage te dit par exemple
* Si c'est compilé ou interprêté (Les langages qui permettent de créer et d'executer dynamiquement du code peuvent difficilement être compilés)
* Si tu travailles en sémantique de valeur ou de référence (si tu manipule des objets ou des des pointeurs)
* Quelle est la gestion de la mémoire (garbage collection ou libération manuelle)
* Si tu fais des tests de débordement ou pas
* Si la résolution de la surcharge de fonction est statique ou dynamique (virtual ou pas en C++)
...
[^] # Re: Comparaison de neuf langages sur un micro-benchmark
Posté par Matthieu Moy (site web personnel) . En réponse à la dépêche Comparaison de neuf langages sur un micro-benchmark. Évalué à 7.
Maintenant, c'est un fait que le fait de programmer dans un langage de haut niveau permet souvent d'écrire des algos avec une meilleure complexité moyenne.
C'est ce que j'explique toujours aux gens qui pensent que l'assembleur est le meilleur langage pour faire du code efficace : Avec une main d'oeuvre réduite, c'est souvent faux. Si tu me donnes 5 minutes pour faire un tri de tableau, si je le fais en C, je vais faire un quicksort (n.log(n) en moyenne, n^2 dans le pire cas), en assembleur, je vais faire un tri par insertion (n^2), et en C++, je vais utiliser la STL qui a déjà tout fait pour moi (Un mélange de quicksort, de tri fusion et de tri par insertion si mes souvenirs sont bons. l.log(n) dans tous les cas.). D'ailleurs, en C++, il me reste 4minutes30 pour aller prendre un café ;-)
Je ne parle même pas de table de hash, de pattern-matching d'expressions régulières ou autres algos un minimum compliqués !
[^] # Re: Comparaison de neuf langages sur un micro-benchmark
Posté par Matthieu Moy (site web personnel) . En réponse à la dépêche Comparaison de neuf langages sur un micro-benchmark. Évalué à 8.
> bien fait, les mêmes résultat,
Ben ça sert à quoi alors de compiler avec -O3 ?
Bon, quand on dit qu'on benchmark un langage, en fait, c'est clair qu'on benchmark un compilateur et l'environnement d'execution, mais bon.
Tu écrit
x = y + z;
t = x + w;
a = b + c;
Maintenant, tu as
Déjà pour un langage interprêté, pour faire y + z, il faut faire un switch sur l'opérateur (voire un appel de fonction), voir que c'est un "+", puis l'executer. Donc, si tu as les mêmes performances en lisp interprêté et en C, y'a de quoi se poser des questions.
Ensuite, est-ce que y et z sont passés par valeur ou par référence. En Java, si x et z sont des "Integer", il faut deux indirections de pointeurs. Ca coûte cher !
En Ada, y + z fait un test de débordement et lève potentiellement une exception (sauf si tu l'as désactivé à la compilation), pas en C.
Maintenant, entre deux compilateurs C.
Tu as celui qui a géré n'importe comment ses registres, qui a mis y et z dans la mémoire, et puis celui qui a mieux optimisé ses registres, et qui a déjà y et z dans des registres. Hop, on économise deux instructions "load".
Ensuite, tu as le compilateur con qui compile tout ça dans l'ordre, et qui est obligé d'attendre que x = y + z; soit fini pour commencer t = x + w; et celui qui a remarqué qu'en executant à la place
x = y + z;
a = b + c;
t = x + w;
On avait la même sémantique, mais qu'on utilisait mieux le pipelining du processeur. Et oui, le même ensemble d'instructions assembleurs ne s'executent pas à la même vitesse selon l'ordre dans lequel elles passent. Fait du pas à pas avec gdb dans du code compilé avec "-g -O3", tu verras que le curseur revient parfois en arrière.
Maintenant, tu as raison sur le fait qu'il y a bien d'autre choses à benchmarker. (les parcours de tableaux par exemple, c'est un cas d'école en matière de compilateur optimiseur).
[^] # Re: Et les icônes ?
Posté par Matthieu Moy (site web personnel) . En réponse à la dépêche GTK-Qt-OpenOffice.org: un pas de plus vers une meilleure intégration. Évalué à -1.
Si on dit "Gnome 2.4 suit MacOS X", ça te va mieux ?
[^] # Re: C'était mieux à vent
Posté par Matthieu Moy (site web personnel) . En réponse au journal C'était mieux à vent. Évalué à 6.
# La fusion nucléaire : On en faisait déjà avant ;-)
Posté par Matthieu Moy (site web personnel) . En réponse au journal C'était mieux à vent. Évalué à 1.
On fait de la fusion nucléaire sur le soleil, qui a la bonne idée de nous en envoyer le résultat sous une forme pas trop nocive. (lumière)
On fait capter cette lumière par des arbres.
On coupe les arbres, et on en replante.
On brule le bois qu'on a coupé
On récupère l'énergie dégagée
Les arbres recoupés récupèrent le CO2 dégagé.
C'est con, mais les hommes préhistoriques faisaient comme ça et ils avaient bien raison (sauf qu'au lieu de planter, ils attendaient que ça repousse !)
[^] # Re: C'était mieux à vent
Posté par Matthieu Moy (site web personnel) . En réponse au journal C'était mieux à vent. Évalué à 2.
Le soleil nous envoie 1200 W/M^2.
Il faut diviser par deux pour enlever la nuit, et encore par deux pour prendre l'intégrale sur une journée.
Il reste 300 W/m^2.
Ensuite, tout est question de rendement. Pour l'instant, on a des rendement dégueulasses (si mes souvenirs sont bons, de l'ordre du %). Si la recherche avance à ce niveau là, qu'on arrive à faire mieux et pas trop cher, tu remplaces les tuiles de ton toit par des panneaux solaires et ça alimente ta maison. (100m^2 * 30W/m^2 = 3Kwatts, c'est très raisonnable).
Pour l'instant, on peut alimenter sa maison en faisant comme ça si on économise l'électricité au max (Je connaissais quelqu'un qui avait fait ça a une époque, il revendait le surplus à EDF ou consommait quand il n'y avait pas de soleil, il était à peu près équilibré.). Mais bon, c'est pas tout rose non plus : lampes à économies d'énergie : visiblement c'est un bon truc niveau écologie, mais il y a quand même du mercure dedans, chauffage/cuisine au gaz : rejet de gaz à effets de serre, etc ...
La question est : Si on avait mis les thunes qu'on a mis dans le nucléaire pour le solaire et réciproquement, où en serait-on ?
[^] # Re: C'était mieux à vent
Posté par Matthieu Moy (site web personnel) . En réponse au journal C'était mieux à vent. Évalué à 2.
Parce que : SCOOP : Les centrales nucléaires non plus, on ne les éteint pas la nuit !
Donc, on utilise les barrages pour réguler la quantité d'énergie à court terme (journée) et à échelle d'une saison (les barrages sont vides à la fin de l'hivers en général). Soit on les arrête la nuit, soit carrément, comme à grand-maison au dessus de Grenoble, on pompe à l'envers la nuit.
[^] # Re: Mais a quoi servent Gnome et KDE
Posté par Matthieu Moy (site web personnel) . En réponse au journal Mais a quoi servent Gnome et KDE. Évalué à 2.
GNOME et Kde, c'est d'abord des bibliothèques pour les applications. On peut citer la boite de dialogue toute faite pour l'impression, et la gestion des composants graphiques (bobono, kparts) en plus dans ta liste.
Expérience : désinstalle Gnome et/ou Kde de ta machine, et regarde ce qui reste.
Rien ne t'oblige à utilser Gnome/Kde en temps que bureau, mais que les applications que tu utilise fassent elles-même appel à eux, c'est important.
[^] # Re: sauvegarde à chaud
Posté par Matthieu Moy (site web personnel) . En réponse au journal sauvegarde à chaud. Évalué à 2.
Ben si tu fais ça a chaud, t'es dans la m**** !
Mettons que tu commence par sauver une table de inodes au début de /dev/hda, ton 'dd' continue à gratter, pendant ce temps, un utilisateur fait un 'rm toto'. Quand le dd arrive sur l'emplacement physique de toto, le fichier a été effacé, potentiellement écrasé, mais ta table de inodes sauvegardée pointe toujours dessus.
bon, le "init 1" te sauve, là, mais encore, ton kernel peut très bien décider de flusher son cache au milieu, ou une connerie du genre, et là, ...
Bref, ça marche "bien" sur des machines pas chargées, mais je déconseille fortement ce genre de truc sur un serveur chargé.
[^] # Re: GTK-Qt-OpenOffice.org: un pas de plus vers une meilleure intégration
Posté par Matthieu Moy (site web personnel) . En réponse à la dépêche GTK-Qt-OpenOffice.org: un pas de plus vers une meilleure intégration. Évalué à 4.
Les gens qui voudront un truc rapide feront du Gtk natif, ceux qui seront prets a sacrifier un peu pourront faire du Gtk-Qt. Mais le "un peu" sacrifié, ce n'est que pour le dessin des widgets, donc, par exemple, pas pour le boot.
[^] # Re: Sortie de Gimp 2.0 pre1
Posté par Matthieu Moy (site web personnel) . En réponse à la dépêche Sortie de Gimp 2.0 pre1. Évalué à 1.
(Et non, c'est même pas une blague : http://siliconrealms.com/mdeskinfo.shtml(...))
[^] # Re: Sortie de Gimp 2.0 pre1
Posté par Matthieu Moy (site web personnel) . En réponse à la dépêche Sortie de Gimp 2.0 pre1. Évalué à 3.
Ah ouaaaais, trop bien !
Ben maintenant, essaye de faire une couverture de magazine avec xfig qu'on rigole. Je veux dire un truc avec plus que les 32 couleurs que xfig gère, des dégradés, éventuellement de la transparence, tout ça, quoi ...
[^] # Re: Sortie de Gimp 2.0 pre1
Posté par Matthieu Moy (site web personnel) . En réponse à la dépêche Sortie de Gimp 2.0 pre1. Évalué à 1.
A t'entendre, on dirait que c'est un bon concept de demander à l'utilisateur d'avoir au minimum 5 fenêtre ouvertes pour pouvoir travailler avec Gimp.
Regardes-les screenshots en Gimp 1.2 par exemple
http://www.gimp.org/the_gimp_screenshots.html(...)
Quelle est la proportion de la surface d'écran utilisée par Gimp ? Pas beaucoup. Avec ce méli-mélo, tu as le choix entre des fenêtres qui se superposent (pratique, la boite d'outils par dessus ton image ! Il faut la déplacer à chaque fois que tu veux travailler sur l'endroit qui est en dessous ...), ou beaucoup d'espace inutilisés entre les fenêtres (sur les screenshots, on voit en général plus le fond d'écran que Gimp lui-même.)
Sans aller jusqu'aux fenêtres dans les fenêtres, la possibilité d'avoir des tabs avec plusieurs images groupées serait déjà pas mal. (Tout le monde n'utilise pas pwm ...) La possibilité de docker les boites de dialogue dans la 2.0 est un grand pas en avant à ce niveau là.
Sinon, pour le bouton droit de la souris sous Mac, moi, les mac-eux que je connais, une fois qu'ils ont touché à Windows, ils regrettent de ne pas l'avoir (idem pour la molette ...)
[^] # Re: Sortie de Gimp 2.0 pre1
Posté par Matthieu Moy (site web personnel) . En réponse à la dépêche Sortie de Gimp 2.0 pre1. Évalué à 3.
Gegl -- Generic Graphical Library --- is an image processing library based on GObjects.
En gros, l'idée est de mettre toutes les fonctions de traitement d'image dans une librairie bien propre, et Gimp serait plus ou moins un front-end à tout ça.
C'est à mon avis une *excellente* nouvelle : De la même manière que Gimp a crée son propre toolkit (Gtk, à la base, c'est Gimp ToolKit), qui a été réutilisé et amélioré par plein d'autres applications, on peut espérer voir naitre un projet similaire à Gimp pour KDE par exemple, avec une autre interface, mais des fonctionalités similaires, les progrès de l'un bénéficiant à l'autre.
[^] # Re: Sortie de Gimp 2.0 pre1
Posté par Matthieu Moy (site web personnel) . En réponse à la dépêche Sortie de Gimp 2.0 pre1. Évalué à 7.
(Marche sous Gimp 1.3)
[^] # Re: Sortie de Gimp 2.0 pre1
Posté par Matthieu Moy (site web personnel) . En réponse à la dépêche Sortie de Gimp 2.0 pre1. Évalué à 1.
Oui !
> pour avoir qulque chose d'utilisable
Prèsque !
Les changements les plus visibles : Il y a un menu horizontal en haut de la fenêtre dessin. (Les sous menus étaient très chiants à atteindre à la souris).
Une vision assez sympa pour regrouper la multitude de petites boites de dialogues qui trainaient partout : On peut avoir plusieurs boites de dialogues dans une fenêtre avec des tabs, et en plus, on peut couper les fenêtres en deux horizontalement. Bref, ils ont ajouté les fonctionalités intéressantes de ion, quoi ;-)
Le truc que je trouve dommage : visiblement, on ne peut pas utiliser tout ça avec les fenêtres qui contiennent les images. Là, c'est encore une fenêtre du window manager par image.
[^] # Re: Un député écrit aux ministres au sujet des logiciels libres
Posté par Matthieu Moy (site web personnel) . En réponse à la dépêche Un député écrit aux ministres au sujet des logiciels libres. Évalué à 2.
>> la prise en compte dans une version ultérieure du CCI."
[...]
> Ils ont intérêt à vraiment l'ouvrir leur format 8-)
http://www.microsoft.com/france/infos/presse/2003/11/info.asp?mar=/(...)
"Microsoft rend disponible les schémas de référence XML d'Office 2003"
Tu disais ?
(D'ailleurs, c'est pas un hasard que tout ça se passe en même temps. MS a bien compris qu'ils perdraient le marché des administration puis petit à petit bien d'autres si ils n'ouvraient pas leurs formats ...)
(Par contre, ce qui est crétin, c'est que quand tu va télécharger leur truc, c'est un fichier .exe -- Faut pas abuser des bonnes choses !)
[^] # Re: Tiens, un bug dans firebird :)
Posté par Matthieu Moy (site web personnel) . En réponse au journal Tiens, un bug dans firebird :). Évalué à 2.
[^] # Re: Pourquoi Linux n'est pas prêt pour le desktop ?
Posté par Matthieu Moy (site web personnel) . En réponse au journal Pourquoi Linux n'est pas prêt pour le desktop ?. Évalué à 2.
http://linuxfr.org/~kapouik/7749.html(...)
"Il y a un an, j'ai supprimé définitivement ma partition Windows [...], à part pour jouer, ça fait des années que Windows ne me servait vraiment plus à rien."
[^] # Re: Ability Office ? kezako ?
Posté par Matthieu Moy (site web personnel) . En réponse au journal Ability Office ? kezako ?. Évalué à 1.
La homepage tout en flash et javascript ! tout ça pour quoi, juste avoir un bouton "bienvenue" et un "welcome".
Ensuite, tout se passe bien sous Moz ou links.
http://www.carrefour.com/francais/homepage/index.jsp(...)
# Re: les clefs ssh
Posté par Matthieu Moy (site web personnel) . En réponse au journal les clefs ssh. Évalué à 3.
m'enfin en gros, c'est
ssh-keygen -t rsa
(passphrase vide pour les premiers essais, mais ensuite, il *faut* vite apprendre à utiliser ssh-add et ssh-agent et avoir une passphrase ...)
Puis tu envoies ton ~/.ssh/id_rsa.pub à la personne chez qui tu veux te logger, qui fait un
cat id_rsa.pub >> ~/.ssh/authorized_keys
Et c'est dans la poche ...