Yusei a écrit 4649 commentaires

Ce qui ne me convient pas, pour l'instant, n'est pas la machine mais linux.

Si à la question "qui est responsable du mauvais support d'une carte vidéo" tu réponds "les développeurs de Linux/X11/...", alors c'est Linux qui ne te convient pas. Mais si, comme la plupart des utilisateurs de Windows, tu estimes que le support de ton matériel est la responsabilité du constructeur, le coupable est Intel et/ou Packard Bell, non ? Ça ne viendrait à l'idée de personne de gueuler sur Microsoft si une carte vidéo était vendue sans le driver qui va bien.

Ceci dit, tu n'as pas dû avoir de chance, car j'ai acheté un Packard Bell à 999 euros aussi, et tout fonctionne très bien, sauf son lecteur de cartes mémoires, que je n'ai jamais essayé de faire fonctionner. Comme quoi on peut être pingre et avoir quand même un truc qui marche :)

http://live.gnome.org/MemoryReduction(...)

Ils y passent:

http://live.gnome.org/MemoryReduction(...)

Ça peut éventuellement être compliqué si on lance l'ordre de copier un fichier, alors que dans la queue il y a un ordre de déplacement du même fichier. Ça peut se résoudre, mais dès que les choses sont un peu compliquées, on est tenté de ne pas se donner la peine de le coder :)

La formulation laissait effectivement penser à un troll: demander si c'est "corrigé" laisse entendre qu'il s'agissait d'un bug. Étant conscient qu'il s'agit d'un choix, tu peux ne pas être d'accord avec, mais le traiter comme un bug est plutôt méprisant pour ceux qui ont fait ce choix.

J'ai l'impression que selon ce raisonnement, soit on est un débutant (terme que tu utilises juste au dessus), et dans ce cas, on ne nous montre que ce qu'il faut (un débutant n'utilisera-t-il jamais de répertoires pour classer ses fichiers?,[...]), ou alors on est un utilisateur expérimenté, et on fait "ctrl-S_ctrl-L...", comme tu dis. Rien entre les deux?

Entre les deux, il y a la possibilité de cliquer sur la zone qui affiche la liste de dossiers. Certes, c'est plus long que d'avoir directement la liste, mais de là à faire comme si ça n'était pas possible...

Bon, ceci dit, je suis surpris que les développeurs de Gnome/Gtk n'aient pas opté pour la solution de facilité: mettre une clé gconf cachée qui permet d'afficher toujours la liste des dossiers. Ça ne doit pas être très difficile, et ça faciliterait la vie à ceux d'entre nous qui savent ce qu'est un dossier.

(En tout cas, le choix de Gnome n'est pas si idiot qu'on peut penser... j'ai dans mon entourage des gens qui sont paniqués par la vue d'une liste de dossiers/fichiers, et qui sont ravis de pouvoir enregistrer leurs documents en vrac dans leur home, d'un simple clic)

Un coup de couteau dans le dos de KDE ? Il y a peut-être une raison pour laquelle les développeurs de KDE ont décidé d'utiliser une licence libre...

(Et du côté de Nokia, vu la mémoire disponible sur la bête, on peut comprendre qu'ils n'aient pas envie de fournir toutes les bibliothèques graphiques existantes)

Pour moi au contraire, la LGPL est un serieux handicap.

Juste par curiosité, tu veux dire que tu considères la LGPL comme un handicap par rapport à la GPL, ou bien par rapport à une licence non libre ? Parce que finalement, j'ai l'impression que tu dis plus ou moins que le libre est moins bien que le propriétaire, car le support est garanti dans le cas du propriétaire. Dans le cas de QT, on a la chance que les gars de TrollTech soient sympas, et diffusent une version GPL, mais ça ne change pas l'argument.

Dans le cas d'une bibliothèque propriétaire, il y a peut-être un certain support, mais il n'est garanti que tant que l'éditeur survit, et tant qu'il développe la bibliothèque. Ceux qui ont choisi de développer avec Motif doivent être bien contents que Lesstif existe, en libre, par exemple. Je ne sais pas ce qu'est devenu Motif, mais ça fait longtemps que je n'en ait pas entendu parler.

Ah si, ça marche, c'est une certitude. Par contre je ne sais pas si son problème vient de là.

Le fonctionnement de make est un peu traître, car les variables ressemblent à des variables d'environnement. On aurait donc envie de faire:
> CC=gcc-3.3 HOSTCC=gcc-3.3 make bzImage
Et ça, effectivement, ça ne marche pas, car il s'agit de variables qui sont définies dans le makefile. Par contre,
> make CC=gcc-3.3 HOSTCC=gcc-3.3 bzImage
indique à make la valeur que l'on veut donner à ces variables.

Si jamais ton problème est lié à l'utilisation de GCC 4, et que tu en as un autre, par exemple le 3.3, tu peux essayer un:
make CC=gcc-3.3 HOSTCC=gcc-3.3 bzImage

Chez moi, cette méthode marche:
- apt-get install openbox
- killall metacity && openbox
- se déloguer en enregistrant la session

Bof, il cite apt, qui est une des raisons pour lesquelles je suis content d'être sous linux, et c'est pas spécialement fourni par KDE :)

En fait le SMIL n'est pas spécialement un format pour l'animation SVG, mais pour le multimedia en général. Ça permet par exemple de synchroniser une vidéo avec un sous-titrage, le tout au milieu d'une image SVG qui bouge. Ce qu'on peut faire avec SMIL est assez proche de ce qu'on peut faire avec Macromedia Director©®(tm).

Ce que je voulais dire c'est que le goût littéraire n'est pas forcément une question d'âge.

Ce que je voulais dire c'est que la qualité littéraire n'est pas forcément une question d'âge du public. Pour prendre en exemple un des auteurs que tu as cité, "Le Hobbit" est un livre pour enfants, et pourtant je prend encore plaisir à le relire.

Pour la première fois depuis des années, j'ai eu des popups aujourd'hui... et je viens de mettre à jour pour la version 1.0.6 du package debian. Je soupçonne un bug. D'autres expériences ?

Stocker en primaire ? Peuh... moi j'ai lu Tolstoi à la grande section de la maternelle. On a bien essayé de me faire lire "Jojo Lapin et la carotte magique", mais la bibliothèque rose c'est pour les tapettes.

La liberté pour moi, c'est d'appeler mon système comme je veux.....

Si tu fais référence au fait qu'il demande aux gens de dire "GNU/Linux", je me permet de te faire remarquer que sa demande n'influe en rien sur ta liberté d'accepter ou de refuser de le faire.

Et la remarque n'est pas hors sujet, puisqu'ici, ceux qui influent sur notre liberté de dire ce qu'on veut, ce ne sont pas les gens comme RMS mais plutôt Scholastic (l'éditeur de HP en amérique du nord). Certes, dans le cas de HP c'est dérisoire, et ça aurait prété à rire si les tribunaux ne leur avaient pas donné raison...

Mieux qu'attendre la sortie en poche: acheter la version anglaise, c'est moins cher (et ça fait apprendre l'anglais) :)

On parle beaucoup des fans qui se sont rués sur le livre dès sa sortie... moi je me suis contenté de le pré-commender parce qu'il y avait une réduction de 35%. Sachant que de toutes façons j'allais le lire un jour... (ceci dit j'ai été très déçu par le tome 6).

Hum, si tu as vu le 1 et que tu n'as pas aimé, rien n'est perdu car:

- Ce film est le plus mauvais des trois, le moins mauvais étant le dernier en date. Dans le premier film, le réalisateur est tellement content de ses jolis effets spéciaux qu'il oublie complètement qu'il y a une intrigue (et du coup le grand méchant de la fin semble tomber du ciel, on n'a fait que l'entrevoir quelques instants auparavant).

- Le "niveau" des livres est censé suivre l'âge des lecteurs. Le premier est destiné principalement à des enfants de 10 ans, ce qui explique la légèreté de l'intrigue, mais les suivants se développent assez vite.

Ceci dit, rien ne t'oblige à aimer, ou même à essayer, mais bon juger sur le premier livre c'est pas forcément très pertinent dans le cas présent... et sur le premier film encore moins.

Sauf erreur, tout est sous licence art libre, y compris les cartes... mais ça rame trop pour que j'aille regarder le contenu des fichiers.

Je pense que si le libre proposait des polices manuscrites indéchiffrables, ça pourrait etre un bon argument pour conquérir ce marché, non ?

(Et là je me fouette avec des orties, il s'agissait de variables d'instance et pas de variables de classe... Mais histoire de ne pas poster pour rien, j'en profite pour préciser que l'initialisation à Nil est valable aussi avec les variables globales, comme $toto)

En fait en Ruby, comme en Perl (mais en Perl on a un mode strict si on veut), les variables sont automatiquement créées:
a = 2
crée la variable a et lui affecte 2. Par contre, lorsqu'on utilise une variable pour autre chose que l'affectation, soit on se heurte à un objet initialisé à Nil, qui n'a pas la méthode qu'on essaye d'utiliser, soit on se heurte à un "NameError: undefined local variable or method". Ce n'est pas idéal, mais au moins la plupart des erreurs que l'on pourrait identifier tout en gardant le typage dynamique sont identifiées assez vite. Par exemple, impossible de faire
> toto = 2
> a = 3 + totp
NameError: undefined local variable or method `totp'

Ou bien avec des variables de classe (qui elles sont initialisées à Nil)
> @toto = 2
> a = 3 + @tpto
TypeError: nil can't be coerced into Fixnum

Ruby:
+ langage objet, pas seulement "orienté objet" comme le C++ ou Java
+ syntaxe agréable, conçue pour optimiser le programmeur
+ un petit côté fonctionnel avec ses blocs
+ aussi flexible/expressif que le Perl, le côté "tout objet" en plus
+ la bibliothèque de base est bien fournie, il existe beaucoup de "contributions", et il est très facile de l'interfacer à une bibliothèque en C
- le typage dynamique, c'est bien pour coder rapidement, mais ça rend la détection des bugs plus compliquée (pas de "copmpile-time")
- la VM actuelle est lente

Pour quelqu'un qui n'a jamais fait de programmation, les deux sont aussi (non) intuitifs

Je ne donnais la version en C que pour que les non initiés comprennent ce que veux dire (e -> e -> e), mais ceci dit, à la réflexion, je pense quand même que c'est plus intuitif: on a une fonction qui a clairement deux arguments et une valeur de retour. Ça serait encore plus intuitif noté comme en maths, f: (e, e) -> e.

La notation du lambda-calcul, elle, contient un "piège", qui est que l'on n'a pas besoin de donner tous les arguments, et que dans ce cas on obtient une fonction. En réalité, il aurait fallu que je note (e -> (e -> e)). Attention, je ne critique pas ça, je trouve les langages fonctionnels très pratiques et élégants, mais pour quelqu'un qui vient des maths traditionnelles, je ne trouve pas ça spécialement intuitif :)

Tel qu'il est présenté traditionnellement, le lambda-calcul est non-typé.

Tu as vu que je parlais de la notation de l'inférence de type, et pas la notion ? Cette notation est la même notation que celle utilisée pour le lambda-calcul typé, ce qui est une bonne chose si on en a déjà fait, mais qui n'est pas évident sinon.

Tu sais, le fameux: (e -> e -> e) qui désigne une fonction qu'en C on écrirait "e f(e, e)".

en caml il n'y a que des expressions

Oui, et contrairement à d'autres langages fonctionnels plus "purs", il y a des expressions qui ne retournent pas de valeur mais on des effet de bord. C'est pratique mais ça complique les choses.

ouais enfin il n'y a que deux familles d'opérateurs, ceux pour entiers et ceux pour flottants qui ont un point en plus. C'est pas la mort à mémoriser.

C'est faux, il y a des opérateurs différents pour tous les types. Par exemple l'opérateur de "construction de liste" (je ne sais pas comment ça s'appelle exactement) est différent selon le type de "liste" que l'on manipule. Pour une liste c'est [ et ], pour un vecteur c'est [| et |]. C'est comme ça pour tous les opérateurs, puisqu'un opérateur est une fonction dont le type ne peut pas varier.