Batchyx a écrit 1261 commentaires

LaTeX ne fait pas d'échappement du caractère antislash comme le fait GCC.

Pour faire des antislash en latex, le plus simple est de se mettre dans un mode verbatim, dans ce cas la il n'y a pas d'échappement à faire. Et franchement, je vois pas l'utilité de mettre un antislash ailleurs que dans un verbatim dans un document correctement typographié (sauf en math, mais dans ce cas c'est backslash, parce que c'est pas n'importe quel antislash).

Comme d'habitude il n'y a aucun rapport. Les technos de Windows non plus ne sont pas des clients X, et pourtant ils supportent la déportation. Et ce n'est pas au client X de supporter la déportation, c'est plutôt au serveur.

Pas d'accord. Il y a un tas de trucs à installer. Ces trucs, ils se sont installés lorsque ton admin system a installé ta distribution.

Je te défie d'installer un serveur X et de m'empêcher de faire du déport en ayant pas installé les applis nécessaire. Même des serveurs minimalistes comme Kdrive le supportent. Ça serait plus de la malveillance que de l'incompétence.

Quand on est root sur sa distro on trouve toujours une solution, je me fait pas de soucis pour ça. Mais quand on est pas root, c'est une autre paire de manche.

Et l'histoire d'un autre projet puisse se développer, j'en ai rien à foutre, j'ai rien contre ça. Mais quand on remplace un truc avec le déport qui marche par un truc sans et que contourner ce manque est chiant, je me réserve le droit de gueuler. Je ne vois pas pourquoi wayland n'intégrerai pas un support de base pour la déportation. On est en 2011, quand même.

C'est moi ou je ne vois absolument pas le rapport entre ce que tu dit et ce que je dit ?

Tu me parle de choisir des distributions, moi je te parle que je suis simple utilisateur et que je n'ai pas les droits root. Si je peux me logger sur deux machines, je peux faire du déport X11 sans rien demander à mon idiot d'admin système, puisqu'il n'y a rien à installer. Et dans ce thread on dit que pour faire la même chose avec wayland, faut télécharger et d'installer des applis. Moi je dit que c'est pas la même chose.

Et on peut très bien installer des applis X sans pour autant avoir un serveur X sur la même machine, grâce à quoi ? la déportation.

• Il faudra m'expliquer en quoi &Exemple::Add est un pointeur foireux. Parce que pour le reste, les pointeurs sur méthodes sont chiants à déclarer et manipuler, et donc personne le fait.
• Ce n'est pas sans intérêt, je rappelle ici qu'on est en C++. Ce pointeur ne sert pas tant à dire quel objet ça s'applique mais surtout comment est la relation de propriété (qui va s'occuper de l'objet, qui va le détruire). bind pourrait très bien être propriétaire de l'objet ou avoir une propriété partagée. Et non, il n'y a pas de relation de propriété qui convient dans tout les cas.
• Je ne vois rien d'inline dans les brevets.
• La syntaxe n'est pas lourde, comparé à d'autres aspects du C++. Et elle est surtout bien plus puissante. Si tu à deux événements et que tu doit faire la même chose à un paramètre près, tu n'est pas obligé de te farcir deux méthodes qui en appelle une troisième. Tiens vais faire un brevet :) ...

#include <boost/function.hpp>
#include <boost/bind.hpp>
#include <iostream>

typedef boost::function<int(int,int)> OperationDelegate;

struct Console {
     void Print(OperationDelegate del) {
          int res = del(42,3); // appel safe pasque gnagnagna
          std::cout << res << std::endl;
     }
};

class Exemple {
    int i;
public:
    Exemple() : i(42) {}
    int add(int a, int b) { return a + b + i; }
    int add3(int a, int LOL, int b) { return (a + b + i)*LOL; }
    void Test() {
         Console c;
         c.Print(boost::bind(&Exemple::add, this, _1, _2));
         c.Print(boost::bind(&Exemple::add3, this, _1, 1 /* valeur de LOL */, _2));
         // variante inline pour c++11
         c.Print([](int x, int y) { return x + y; });
    }
};

Oui, et ensuite ?

Dans le cas de boost::bind, le type c'est boost::function<int(char,float)> (fonction prenant un char et un float et retournant un int). boost::bind permet de généraliser et d'utiliser par exemple une méthode de tel objet, ou une fonction à trois paramètres en disant que le deuxième est NULL, ou une combinaison des deux. Je ne vois pas en quoi ça n'a "rien à voir".

Ou si on utilise que la STL, on est limité au méthodes ne prenant qu'un argument, et le type est template <T> binder1st<T,Argument>, il faut juste effacer le type T avec du type erasure.

En gros, si j'ai bien compris, c'est la même chose que boost::bind en C++ ? Sachant que boost::bind n'est qu'une généralisation de fonctions de la STL (bind1st, mem_fun...), qui datent de 1994 ?

Il est toujours possible de faire tourner X en tant que client Wayland, le support de X ne disparaîtra pas si tôt. De plus, il existe d'autre protocole pour faire ça, je pense à Spice qui a déjà été cité. Il ne faut pas croire que seul X peut le faire, les autres ne le feront pas en natif mais ce n'est pas pour ça qu'ils en sont incapable.

Le principal avantage du déport X11 natif par rapport à d'autres solutions, c'est quand même que c'est disponible de base et qu'il n'y a pas besoin de demander à l'admin réseau d'installer des trucs sur ta machine ou de le faire soit-même (quand c'est possible...) pour que ça fonctionne. Ça juste marche en 2s. Est ce qu'on pourra en dire autant de wayland ? Ou est ce qu'on pourra rien faire si on à oublié d'installer le logiciel de déport supplémentaire et qu'on à pas d'accès internet à disposition ?

Bien sûr qu'il y a une grosse perte de perf. Chez mes parents les coms skype sont super moche avec plein de coupures/déconnexions si je ne configure pas le routeur et skype. Alors parler de logiciel qui marche en cliquant sur suivant/suivant c'est de la grosse blague, on fini bien souvent les appels avec un téléphone classique.

Faudra pas me dire que le traversal de nat non-coopératif n'est pas un mode dégradé.

Mouai… enfin cet argument ne tient pas : intrinsèquement, ce ne sont pas les œuvres indisponibles qui rapportent de l’argent au sociétés d’auteurs.

Bien-sûr que si, c'est comme les machines à laver. Avant on faisait des modèles fiables. Maintenant tu n'en trouve plus un seul sur le marché. Et le renouvellement de machines en pannes rapporte directement de l'argent aux fabriquants.

Pour la musique c'est pareil, c'est comme ça qu'on gère les modes : si on distribue plus de variété et que l'on arrête d'en produire, ça passe de mode et ça laisse plus de place à la nouvelle mode... qui est bien plus chère.

Le monsieur explique qu'en utilisant les DNS de google, il y a toujours la redirection. Si c'était des DNS menteurs, le problème aurait été résolu. Le problème ne vient donc pas de là.

C'est peut être comme ce que Numéricable fait (ou faisait, j'ai pas vérifié) : les DNS ne mentent pas, mais DHCP configure le suffixe DNS par défaut comme étant ".numericable.fr", donc quand tu tape une adresse inexistante www.example.com, tu va essayer www.example.com.numericable.fr et comme y a un wilcard *.numericable.fr, tu peut te faire rediriger.

Mais il y a un avantage : avec un poil de configuration, ton client DHCP peut ignorer le suffixe DNS ;)

T'était sûr que c'était IE6 ? je me souviens d'une histoire avec IE5, ou l'un des développeurs avait critiqué le fait que l'on sorte des logiciels sans qu'ils soient bien finalisés, juste pour contrer la concurrence. Il à fait ça sans citer MS, IE ou Netscape, mais ça transpirait assez pour que l'on comprenne.

je crois qu'inclure stdio.h suffit pour que cette fonction pas standard puisse être utilisée.

Sinon le comportement de windows qui consiste à fermer le terminal dès que le programme est terminé est configurable. Et sous visual studio, lancer le programme sans debogueur suffit pour que la fenêtre ne se ferme pas quand le programme se termine. va savoir pourquoi ça ne marche que en mode non-débogueur...

Effectivement, pour être politique, c'est bien politique. Si c'est pour faire plaisir au copain pdg, tout de suite y a moins de règles pour construire sur l'église classée...

http://videos.next-up.org/France3/OperateurCimetiereProfaneEgliseDefiguree/CastelletLesSausses04122007.html

(désolé c'est du flash, j'ai pas réussi à trouver autre chose)

S'il n'y avait que ça ...

• Il ne détruit jamais ses objets.
• Il y a un getch() à la fin de chaque main(), qui sert strictement à rien.
• Par contre, retourner un int ... c'est pour les chiens. C'est mieux quand c'est une valeur aléatoire.
• il n'y a pas de \n à ses derniers printfs. Pour un programme à utiliser en console, c'est moyen.
• oh une variable globale ... qui n'est utilisée que dans le main.

Un client lourd qui ne fait qu'accéder à une base de données ... j'appellerai plutôt ça un client léger. Ça sert effectivement à rien de recoder un client pour ça.

Pour moi le client lourd, c'est le client qui va télécharger le morceau de base de données qui nous intéresse (de manière transparente, ou à la main) pour y accéder en local, qui va avoir une fonction "tout synchroniser et passer en mode hors ligne/lecture seule/tiens regarde l'historique ilébo", qui permet de sauvegarder des morceaux dans un fichier à mettre sur une clef USB ou autre, et à échanger avec tout ses amis. Dans les cas simples, elle permet de préparer en local des modifications à faire sur la base de donnée.

Enfin bref, comme toutes les clients mails lourd, les messageries instantanées lourdes, les navigateurs lourds, les gestionnaires de versions lourds ...

Tu n'est peut être plus embêté par les contraintes du client graphique, mais tu est quand même lourdement embêté par les contraintes du réseau, ce qui est encore pire. Tu doit gérer le fait que ton réseau perde une connexion au pire moment possible, que le réseau soit coupé entre le moment ou le serveur à reçu une demande de modification et le moment ou il renvoie la réponse positive ... et ceci sans l'aide de l'utilisateur, puisque le bouton "reload" ne marche pas sur du javascript.

Et tu doit surtout gérer le fait de ne pas avoir de réseau du tout, et l'utilisateur veut avoir ses données quand même.

Ça n'a pas empêché de sortir le N900 ou l'openmoko, sans parler des téléphones androids ou tu est déjà root ...

a) merci du tuyau :p

b) C'est idiot, parce que moi en tant qu'utilisateur de base, je ne vois pas la grande différence de fonctionnalités. mon entourage aussi ne vois pas la différence. Ni toutes les personnes que je connais en fait. Alors si c'est pour dire que ton camion de 10 tonnes est capable de déménager ta maison, les utilisateurs ont juste besoin d'une voiture pour aller faire les courses en payant le moins de carburant possible.

Relis bien ce que tu ecris (549Mo) et compare ca avec la video du dessus ou le gars demarre Win7 dans 160Mo et l'article du gars qui trouve que ca tourne bien dans 512Mo, et demande toi si par hasard tu ne serais pas en train de mal interpreter le chiffre que tu lis.

Alors oublions les chiffres. Mon windows 7 avec 1 Go de RAM et quelques gros programmes lancés est plus lent qu'mon athlon xp. Je parle bien d'un OS utilisable hein, pas d'un windows fraîchement installé incapable de lire un pdf ou un tar.gz. je parle d'un os utilisable avec toutes les mises à jour installées ainsi que votre antivirus.

Et si je lance une machine virtuelle avec 512 Mo de RAM allouée, il n'est pas possible de lancer un autre programme sans avoir de gros ralentissements. Heureusement que le linux de la machine virtuelle ne consomme pas autant.

La seule raison pour laquelle ça n'est pas conservé entre les mises à jour que je vois doit être très certainement une raison psychologique et marketting ... genre http://ars.userfriendly.org/cartoons/?id=20020103

Sauf que mon athlon xp, je l'ai pas beaucoup bidouillé pour qu'il soit rapide, contrairement à windows. on parle bien d'OS en utilisation normale dans ce cas. Je n'ai même pas envie d'essayer avec un windows server.

Sinon, c'est très simple d'avoir un windows 7 lent. au démarrage l'OS prend 549 Mo (hors cache disque). Suffit de lancer quelques applis (ff, office, eclipse ...) avant que l'OS s'écroule et swappe. Après faut pas chercher bien loin pourquoi c'est lent quand il reste plus que 27 Mo de cache disque.

Il y a même pas un an, en utilisation normale j'utilisai un portable avec 64 Mo de RAM. pouvait compiler n'importe quoi dessus (du C++, du java, un noyau ...), pouvait faire d'la bureautique avec abiword/gnumeric/LaTeX/xpdf/xdvi, j'pouvais glander sur iceweasel sur des sites pas lourd (même si elinks et nrss étaient plus confortable) et je pouvais, bien sûr, aller causer sur mutt/xmpp/irc ... Bien plus que faire du notepad donc.

Et j'ai parlé du temps de démarrage ? 45 sec en gros. 3 secondes pour lancer un premier terminal, moins d'une secnode pour les suivants ;) Bien-sûr j'ai du autant bidouiller ma debian unstable, un OS encore plus récent que Windows 7 !

Il y a moins de 2 mois, ma machine principale était encore un athlon xp avec (512+256) Mo de RAM. Ça ne m'empêchait pas de lancer iceweasel, icedove, akregator, psi, et plein d'autres bidules occasionnels comme gimp, audacity, eclipse (bon lui il sera toujours lent) et une bonne ribambelle de terminaux. Sans parler de tout les services qu'il faisait tourner (firewall, web, dns, proxy cache pour apt ...), et le tout sans aucun gros ralentissement. Si j'ai rajouté 256 Mo de RAM, c'était pour bourriner plus sur les tabs dans iceweasel, ça marchait tout aussi bien avant.

Je lance windows 7 sur un PC avec 1 Go de RAM et un processeur dual core. même après de nombreux bidouillages, c'est aussi lent qu'avec l'athlon xp rien qu'avec trois programmes ouverts.

Et après vous vous étonnez que beaucoup de monde restent sur de vieux windows.

Vu la vitesse avec laquelle il à formaté son disque sous MS-DOS, il à du agrandir son disque dûr à chaque nouvel OS.

Et s'il avait du tester le son, ça aurai été beaucoup plus drôle : il n'y a plus de driver pour sb16 ou pour une GUS sous windows 7. Et même s'il changéait de carte, depuis Windows XP il n'y a plus de couche de compatibilité sb16 pour les applis DOS (sauf si le driver de la carte son en ré-implémente un) donc Doom n'aurai pas de son.