Troy McClure a écrit 2213 commentaires

c'est un peu abusé de mettre truecrypt dans le même panier que les autres

ça m'attristerait vraiment de constater que sur linuxfr, site où on est très à cheval sur le respect des licenses, il y ait des gens qui trouvent malin d'encourager ce genre de pratique

> Un quasi-Mac à 250€ ?

pas tout à 250€ puisque Leopard coute 129€ , ce qui n'est quand même pas une paille par rapport au prix de la machine

Le premier avantage c'est que je connais c++ et pas java :)

Ensuite pour des projets du genre traitement audio en temps-reel ça repond bien aux contraintes de performance, et actuellement tout l'ecosysteme est à 95% en c++ donc ça reste un choix assez naturel. Après c'est vrai que sur d'autres projets j'aurais un peu plus de mal a dire "seul le c++ répond au cahier des charges"

le probleme c'est le c++ moderne qui repose sur des kilometres de templates et de meta-conneries, qui eux même font l'hypothese que "les ptites fonctions et les ptites classes qui font rien c'est pas grave parce que y'a la bonne le compilo qui fait le menage" . Quand l'optimiseur est activé, ça inline effectivement tout ça en éliminant le code mort et ça va vite. Quand l'optimiseur est off tu te retrouve avec un binaire 5x plus gros (10x si en plus t'as mis du -g) , qui du coup met nettement plus de temps à linker, et surtout qui tourne 25x moins vite (et encore ça peut etre pire)

nan mais attends *personne* n'est obligé d'utiliser les extensions . Si tu tiens à faire du code 100% c99 et rien que c99 libre à toi. Le "probleme" que tu souleves concerne le codeur, et pas l'outil. Les extensions sont là parce qu'elles sont pratiques et que certaines personnes en ont l'utilité je vois vraiment pas quel est le probleme. Tous les compilos c/c++ ont leurs propres specificités quand on s'éloigne du noyau commun (le standard)

ça ne se fera bien sur que si un gentil contributeur propose une news avec un theme associé. Mais pour ça faudrait que les fedoristes et autres gentooistes passent un peu moins de temps à chouiner dans les news ubuntu et se mettent eux aussi à rediger de vraies news

Il y a eu un benchmark assez frappant publié sur phoronix:

http://www.phoronix.com/scan.php?page=article&item=ubunt(...)

Honnetement quand on voit les chiffres ça fait peur, ubuntu devient de plus en lent , et pas qu'un peu. Alors est-ce que c'est spécifique à ubuntu ou bien est-ce que toutes les distribs suivent le même chemin ? est-ce que c'est le benchmark qui est mal fait ? est-ce que le bloat est en train de gagner ?

y'en a déjà un !

http://linuxfr.org/board

raahhh ménon c'est justement les grosses dockapp 64x64 qui donnent tout son bon goût à wmaker. Sinon y'a moyen de reduire la taille des icones du dock, mais seules certaines dockapp extremement bien codées, tel wmhdplop, savent s'adapter à un dock non 64x64

à mon avis ça veut dire que les gens de Qt garderont l'idée et recoderont le bousin eux-même, ce qui évitera à la fois les problèmes de code gruik et de license

la réponse c'est qu'on finit *toujours* par avoir besoin de personnaliser tel ou tel aspect du document. Et c'est à ce moment là qu'on commence à perdre des heures, des jours, des semaines avec latex et ses kilometres de doc filandreuse, contradictoire et inconsistante

et puis quand on a consacré trois semaines à pondre laborieusement 15 slides au style raçé avec latex c'est pas évident d'admettre que ça pue et c'est pas pratique

> Pour ce qui est des performances, certain code écris en C# sont meme plus rapide que du C.

ouuéééé supper , d'habitude c'est les javaistes qui la sortent celle-là. Le super compilo JIT 3-en-un qui compile et optimise de plus en plus ton code à chaque qu'il repasse dans la même portion, un peu comme un rasoir à 42 lames

Avant de faire des compilos qui soit-disant vont plus vite que le C, faudrait déjà faire en sorte que les programmes generés demarrent rapidement et ne bouffent pas des tétrachiées de mémoire

32 bits c'est pratique parce que c'est des float:
- c'est rapide pour faire les calculs (SSE)
- la dynamique est quasi "infinie" (virgule flottante), donc pas besoin de s'emmerder à savoir si telle ou telle opération est susceptible de saturer les 8/16 bits de ton image.

en effet et c'est d'autant plus utile une fois qu'un quelconque bras-cassé à décidé que ça serait une bonne idée de traduire les messages d'erreur en français, en breton etc. , parce qu'avec gcc il ne te reste rien à quoi te racrocher une fois que ton compilateur te parle de "jeton invalide" et autres niaiseries

en fait dans les applis mac, la convention est de remplacer le clic droit par ctrl-clic , et le clic milieu par alt+clic . Et au final je prefere largement faire un alt+clic que de cliquer sur une molette fuyante

ubuntu 8.04 sur un p-m 1.6Ghz, 512Mo de ram: 1m11 pour arriver au gdm , puis 45 secondes de plus pour que gnome arrive peniblement à charger son desktop

ça rame c'est une horreur

Comme de nombreux clients supportent l'affichage de smilaids a partir de hfr ou totoz.eu , on pourrait envisager, en partenariat avec totoz.eu, l'insertion de smileys du genre [:leviagrasaibon] de façon aléatoire dans le backend xml. ça aurait l'avantage d'etre backward compatible avec les vieux coincoins et de permettre l'utilisation de techniques marketting avancées telles que l'animation des gifs.

Cordialement,
Troy

je le dis: super article, ça fait vraiment plaisir de lire ça sur dlfp, bravo à l'interviewé et aux intervieweurs

c'est un clone de matlab

Si c'est la base d'une boite qui poste des "VOTRE PACKAGE INTERNET ET SON INTERFACE DE MISE A JOUR" et autres "ROLLS DES SITES" vas-y lache toi defonce leur le fion.

http://kadreg.org/gallery/chatons/aah.jpg.html

pour faire un bug report par exemple. Si ça pouvait eviter les screenshots en bmp collés dans un .doc zippé et envoyé en document attaché ça serait déjà pas mal

si vous êtes pour le retour de Charles Bronson, pertinentez ce journal !