moi1392 a écrit 730 commentaires

  • # g++ -c stubs.c : ça marche !

    Posté par  . En réponse au journal compiler en c++ pour avoir plus de warnings. Évalué à -6.

    Je pense que g++ sait compiler un fichier stubs.c, voir même un fichier stubs.toto
    C'est quoi ce système de compilation alakon ??
    Qu'il y ait des règles par défaut, c'est très bien. Par contre, qu'on ne puisse pas les surcharger quand on le souhaite, c'est vraiment pourri.

    Ah, et sinon, c++, c'est bon et sans huile de palme, mangez-en !

  • # Encore un store...

    Posté par  . En réponse au journal Le store d'Ubuntu et les logiciels proprios. Évalué à 2.

    Justement, pas plus tard que la semaine dernière, je me dit que je me laisserais bien tenter par torchligth !
    J'ai beaucoup aimé et joué à diablo 2, les critiques le donnent dans la lignée de ce dernier (en même temps fait par les même développeurs) et un effort de portage à été fait, donc un jeux en natif !!
    le hundies bundle 6 n'était plus disponible, une rapide recherche sur le web me dit qu'il est possible de l'acquérir via l'ubuntu store.

    Et là, n'étant pas sous ubuntu, je me retrouve complètement bloqué, pas moyen de trouver où et comment me le procurer légalement.

    Quelqu'un à une idée ? où il faut absolument être sous ubuntu pour pouvoir l'avoir ?

  • [^] # Re: Annonce NVIDIA

    Posté par  . En réponse au journal Half-life 3 sera sous linux. UNIQUEMENT SOUS LINUX !. Évalué à 3. Dernière modification le 13 novembre 2012 à 15:39.

    Depuis on a eu la sixième et la septième. Si Warzone ou 0AD ne font pas peur à un Ironlake, je me demande quel jeu vidéo libre pourrait mettre à plat un IGP HD Graphics 4000.

    Je me demande si le problème n'est pas plutôt dans l'autre sens, les jeux vidéos libres sont fait par des gens qui, entre autre, utilisent autant que possible des cartes avec des pilotes libres, donc s'arrangent pour que ça puisse tourner dessus.
    Sinon, pour mettre à genou n'importe quelle carte, suffit d'augmenter la densité du maillage de tes modèles, tu décuples la quantité de triangles à traiter, tu doubles ou triples la taille des textures, tu ajoutes un shader de la mort qui fait le café avant de valider ton fragment, et c'est reglé.

  • [^] # Re: Déçu

    Posté par  . En réponse au journal Si on commençait un nouvel OS libre de bureau aujourd'hui.... Évalué à 6.

    Pour du dev commercial ( lire "payant", en simplifiant grandement et sans rentrer dans les multiples modèles possibles ), les gens comptent plus, car si ils partent, selon ton modèle, tu perds des moyens de manière bien plus quantifiable et immédiate.

    Je suis d'accord sur la forme, mais fondamentalement, sur le fond, ce sont les rentrées d'argent qui comptent, et si pour cela, il faut effectivement que tu fasses le maximum pour tes clients, tu le feras. Mais qui sont tes clients ?
    Regarde le nombre de pourritures installées sur une machine achetée en grande surface, tu penses que c'est l'acheter de la machine le client dans ce cas là ?
    Regarde les systèmes de "protections anti copie" dans l'os pour tout ce qui est film et musiques, tu penses que c'est l'acheteur du logiciel le client dans ce cas là ?
    Regarde tous les moyens mis en place pour emprisonner les utilisateurs dans une suite de logiciels et de services. Tu penses que c'est l'utilisateur le client dans ce cas là ?

    Dans les développement libre, la partie qui marche mal, et qu'il est très dur de faire faire ce qui est vraiment chiant et qui améliorerait beaucoup son utilisation.
    Par contre, un truc bien, c'est que le développeur est, dans 99% des cas, l'utilisateur le plus important du logiciel qu'il développe, et il ne va jamais rien faire qui lui fasse vraiment chier à l'usage pour satisfaire n'importe quel intérêt qui n'est pas le sien en tant qu'utilisateur de son logiciel.
    Et mine de rien, ça donne souvent des résultats plutôt cool ("eat your own dogfood" comme ils disent)

  • [^] # Re: Annonce NVIDIA

    Posté par  . En réponse au journal Half-life 3 sera sous linux. UNIQUEMENT SOUS LINUX !. Évalué à 2.

    On peut dire que c'est super cool.
    Mais ça n'enlève rien au fait que ce soit cool aussi que nvidia bosse plus sur ses pilotes !

    Et on peut espérer à terme une meilleur intégration, stabilité et de meilleurs performances pour tous les pilotes, proprios et libres, avec en prime une prise en charge des évolutions (noyau, xorg/wayland, …) plus rapide.

    Donc que du bon de ce coté là, même pour ceux qui ne sont pas intéressés par les jeux en question.

  • [^] # Re: nope

    Posté par  . En réponse au journal Half-life 3 sera sous linux. UNIQUEMENT SOUS LINUX !. Évalué à 1.

    Pour donner un exemple, quand les utilisateurs changent le focus d'un jeu plein écran, le multi-écran et la résolution du bureau doivent être restaurés, jusqu'à ce que le jeu reprenne la main. Quand un jeu crash, multi-écran et résolution doivent être restaurés. Ces problèmes doivent être résolus quelque part dans la pile graphique, et les discussions tournaient autour de gnome-settings-daemon, Unity, le noyau, etc. pour établir la meilleure stratégie ; les dévs Unity repartent avec des objectifs à remplir pour Unity, mais heureusement avec l'intention d'offrir une standardisation (vraisemblablement des WM hints).

    en discussion depuis un mois : https://mail.gnome.org/archives/wm-spec-list/2012-October/msg00001.html

  • [^] # Re: Question

    Posté par  . En réponse au journal Gnome-Shell, toujours pas convainquant après 1 an et demi. Évalué à 1.

    kde 4.8.2, debian sid ici. Peut-être un bug corrigé dans la 4.9.
    Je verrai après le dégel.

  • [^] # Re: Question

    Posté par  . En réponse au journal Gnome-Shell, toujours pas convainquant après 1 an et demi. Évalué à 1.

    Moi, je clique sur le K en bas à gauche, il change de couleur (comme quand le menu s'ouvre) mais tant que toutes les icones de la systray ne sont pas affichés (ce qui prend une dixaine de secondes), le menu ne s'affiche pas.

    Dans ma systray, rien d'extraodinaire, tout ce qu'il y a par défaut avec kmix en plus.
    Je vais essayer de prendre un peu le temps de comprendre ce qui se passe.

  • [^] # Re: Question

    Posté par  . En réponse au journal Gnome-Shell, toujours pas convainquant après 1 an et demi. Évalué à 1.

    Moi, je clique sur le K en bas à gauche, il change de couleur (comme quand le menu s'ouvre) mais tant que toutes les icones de la systray ne sont pas affichés (ce qui prend une dixaine de secondes), le menu ne s'affiche pas.

    Dans ma systray, rien d'extraodinaire, tout ce qu'il y a par défaut avec kmix en plus.
    Je vais essayer de prendre un peu le temps de comprendre ce qui se passe.

  • # Et les mobiles ?

    Posté par  . En réponse au journal OSEF. Évalué à 6.

    Pourtant, je trouve que l'engouement est toujours là à chaque mise à jour d'ios ou d'android !

    C'est ce qui est hype qui à changé, les gens s'exitent dès qu'un nouveau thème d'icones apparait sur leur mobile !
    Et les pc ne sont utilisés maintenant que pour jouer et bosser.
    Je connais même des gens qui préfèrent aller sur facebook depuis leur mobile plutôt que depuis un PC avec un grand écran déjà démarré et installé devant eux ! (testé il y a deux jours)

  • [^] # Re: Question

    Posté par  . En réponse au journal Gnome-Shell, toujours pas convainquant après 1 an et demi. Évalué à 2.

    Sous KDE, après les 5 secondes, c'est utilisable normalement.

    J'aime beaucoup KDE (que j'utilise depuis la vers 3.3 et pour lequel j'ai écrit quelques patches) mais cette partie est vraiment un point noir pour moi (entre autre, il y a deux ou trois autres soucis dont je m'acomode)
    J'ai le souci que tu annonces pour win 7, mais sous kde (il est peut-être pire sous win, je n'en sais rien)
    Après que le bureau s'affiche, il faut un certain temps (qui se mesure en secondes, entre 10 et 15 je dirais) avant que le click sue le menu k n'affiche quelque chose ou que alt+f2 me donne krunner :(

  • [^] # Re: kikoolol ?

    Posté par  . En réponse au journal Linus à vu la lumière. Évalué à 10.

    Et dire que c'est moi qui l'ai codé celui là !!
    Mon génie est enfin reconnu des plus grands :D

  • [^] # Re: veille consciente

    Posté par  . En réponse au journal De la finalité du système de notation. Évalué à 0.

    Grillé… ça m'apprendra à répondre sans rafraichir…

  • [^] # Re: veille consciente

    Posté par  . En réponse au journal De la finalité du système de notation. Évalué à 2.

    Du coup tu penserais plus vite avec systemd ? Ou alors plus sereinement avec sysv init ?

  • [^] # Re: kdevelop et tortoisehg

    Posté par  . En réponse à la dépêche KDevelop 4.4. Évalué à 1.

    kdevelop a son propre système de gestion des système de contrôle de sources.
    Il est suffisant pour les tâches simples mais malheureusement assez incomplet pour tout ce qui est utilisation avancée, hors du cadre classique.
    Je ne sais pas s'il y a un greffon HG disponible, à ma connaissance, il gère (au moins) svn et git.

  • [^] # Re: Juste une question

    Posté par  . En réponse au journal KDevelop 4.4 est sorti. Évalué à 1.

    Exactement ;) Je n'en doutait point pour Kdevelop, mais le seul truc dont je doutait était la possibilité d'envoyer directement a gdb un rbreak Plop::set* (ou approchant) ou encore un rbreak Plop::Plop ou trace hop.cc:42 ; actions ; collect $args ; end;

    Je n'ai jamais utilisé rbreak depuis la ligne de commande gdb de kdevelop.
    En général, je m'en sers surtout pour affecter des valeur à des variables (p var = 24), à voir le type dynamique des objets c++ (set print object on, puis p mon_obj) et à activer les break sur les exceptions (catch throw, catch catch, …)

    À priori ça devrait passer, mais faut voir si kdevelop ne se merde par sur le retour de gdb (il parse le retour de gdb, en ignorant, à priori, ce qu'il ne connais pas)

  • [^] # Re: Analyse syntaxique et plugin

    Posté par  . En réponse au journal KDevelop 4.4 est sorti. Évalué à 2.

    Pour compléter, je dirais que ce que j'aime le plus dans le gestion du c++, c'est les "best match" lors de la complétion.
    Si par exemple, j'ai une variable de type int, et que je veux lui assigner une valeur depuis un appel de méthode d'un objet, il va me proposer en premier dans la liste les fonctions de cet objet qui renvoient un int.
    Quand je suis dans une fonction, si je lui demande la complétion sans rien avoir tapé au clavier, il me propose en premier les varialbes, locales du bon type, puis les méthodes de la classe dans laquelle je suis du bon type et enfin, tout ce qui est global.

    Enfin, il gère merveilleusement bien les templates.
    Un std::vector est reconnu comme un conteneur de int, et tout ce que j'ai écrit plus haut s'applique !
    Et ce, même avec des templates extrêment compliqués (templaytes de template, héritage de template, …)
    C'est de très très loin l'ide le plus puissant pour l'analyse et la complétion en c++

  • [^] # Re: Juste une question

    Posté par  . En réponse au journal KDevelop 4.4 est sorti. Évalué à 2.

    • possibilité de faire des rbreak (ou autre commande magique de gdb), ou plus globalement envoyer directement une commande à gdb.

    C'est possible, tu as une invite de commande gdb, je m'en sers régulièrement.

    • possibilité d'explorer les objets (kgdb, qtcreator)

    J'ai pas compris, tu as un dock "variables" dans lequel tu peux demander à voir un objet que tu peux explorer sous forme d'arboréscence, ça marche aussi dans le tooltip quand tu es en mode déboguage. C'est de ça dont tu parles ?

    • affichage de code et possibilité d'avoir des breakpoint placés à la sourie.

    ça marche sans soucis.

  • [^] # Re: Pilotes graphiques libres

    Posté par  . En réponse à la dépêche X.Org est mort, vive Wayland !. Évalué à 1.

    Moins bogué, certes, plus performant, c'est à voir.

    J'ai plutôt tendance à penser le contraire moi.
    Plus performant (architecture proche de DRI pour le rendu 2D, alors que c'était réservé à la 3D avant) mais plus bogué aussi, du moins dans les premiers temps.

    Et je vois déjà les râleurs se plaindre des premières versions qui crashent avec de superbes trolls de compétition élevés au grain non ogm et au mille feuille au kirsh !

  • [^] # Re: Pilotes graphiques libres

    Posté par  . En réponse à la dépêche X.Org est mort, vive Wayland !. Évalué à 3.

    Là je suis d'accord :)
    D'ailleurs, je suis de l'avis de pas plusieurs personnes qui ont posté ici, si je pouvais avoir les mêmes performances avec un pilote libre, je n'hésiterais pas un instant, même à fonctionnalités moindres.
    Du coup, quand dans la pratique, c'est plutôt moins de performances mais plus d'intégration avec X, je comprends que les personnes qui n'ont pas besoin de grosses performances (qui représentent, à la louche, 99,99% des non joueurs de jeux récents), soient très contentes de leurs pilotes libres.

  • [^] # Re: Pilotes graphiques libres

    Posté par  . En réponse à la dépêche X.Org est mort, vive Wayland !. Évalué à 2.

    Je suis d'accord pôur ce qui est du retard sur les standards et les protocoles de X (XRandR seulement supporté par les dernières versions… ça m'a bien fait chier perso)
    Par contre, pour le stabilité (dans X en général), je n'ai jamais eu de gros soucis avec, pourtant je suis souvent très à jour au niveau des pilotes (y compris les version beta).
    Il y a eu quelques versions problématiques, mais en règle générale, on pouvait toujours revenir à une ancienne version.

  • [^] # Re: Pilotes graphiques libres

    Posté par  . En réponse à la dépêche X.Org est mort, vive Wayland !. Évalué à 6.

    Rendu d'objets 3D très gros et très complexes (j'ai des vbo de 1 Go par coupe environ…) et simulation (du cuda sur de très gros volumes de données)
    En fait, s'ils faisaient des cartes avec plus de 6 Go de ram, je suis sur que nos clients les achèteraient et augmenterait la taille de leurs modèles en conséquence. Parce que pour l'instant, pour les algos qui s'y prêtent, c'est juste incomparable en terme de performance avec les versions cpu.

    Et pour te dire, on pousse tellement les cartes à bout, qu'on en arrive même à certifier des gammes de cartes avec des versions de pilotes et récement j'ai même du blacklister une version de bios buggué d'une carte !

  • [^] # Re: Pilotes graphiques libres

    Posté par  . En réponse à la dépêche X.Org est mort, vive Wayland !. Évalué à 7.

    Je pousse à bout une quadro 6000 au boulot (un monstre avec 6 Go de ram !!) et je ne bosse pas dans le jeu vidéo, et je suis bien content de pouvoir bosser sous linux (et mes clients aussi !)

    Donc non, intel n'est pas parfait du tout pour tout ce qui n'est pas des FPS récents.

  • [^] # Re: perforce :-(

    Posté par  . En réponse au journal [PUB] Mon employeur recrute - Boston area - Software Performance. Évalué à 1. Dernière modification le 17 octobre 2012 à 16:19.

    je me suis mis à git p4 il y a quelques semaines car un sous projet de ma boite que je dois utiliser est sous perforce :/

    Pour l'instant, ça marche pas trop mal, mais je n'ai pas encore eu à gérer des branches.

    Donc :
    cloner des sources, faire des modifs, pousser les changements : pas de soucis
    utiliser l'outil de revue de code : je lui envoie direct les diffs de git diff.
    pour tout le reste, il y a eurocard-martercard plus qu'à trouver l'occasion de tester.

  • [^] # Re: nVidia et Mesa

    Posté par  . En réponse à la dépêche Mesa 9.0 est sorti : OpenGL 3.1, OpenCL, VDPAU…. Évalué à 5.

    Pour ne pas trop leur jeter la pierre tout de même.
    Le boulot de dégrossissement et une petite lib de test a été écrite par le dev de chez nvidia en question.
    En plus, sa proposition (qui bien évidement sert les intérêts de sa boite) est très correcte techniquement et est aussi utile dans le cas de deux pilotes libres (pilotes amd et intel, par exemple)

    Donc pour le coup, je trouve ça plutôt cool et à la vue de l'entousiasme des autres développeurs (mesa et intel, pas vu de dev amd dans la discussion), ça à l'air plutôt bien parti et je serais content de voir quelque chose qui s'approche de cette spécification arriver avec les prochaines versions de mesa, xorg et dans les distributions.