moi1392 a écrit 740 commentaires

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)

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++

• 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.

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 !

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.

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.

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 !

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.

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.

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.

Je me basais sur des éléments issues du même catalogue fournisseur.
Et je te confirme que dans mon cas, la RAM représente environ deux mille euros.

Même à 2000€, je ne trouve pas ça excessif du tout pour une boite pour les services critiques.
Après encore une fois, c'est sur que s'il y a beaucoup d'écritures, c'est pas pareil…

Tiens d'ailleurs, il me semble que google publie de temps en temps des stats sur ses serveurs, ça serait intéressant de savoir quels quantités de ram ils mettent sur le machines et les taux de réussite/manque du cache mémoire pour les accès disques. Car à priori, pour tout ce qui est requêtes, c'est purement de l'accès en lecture.
Après, ça serait cool de savoir aussi s'ils envisagent de mettre en place ce genre de solutions pour la partie référencement, enregistrement des données collectées, …

Qu'est ce que tu veux dire par "un ssd de 128 Go c'est pour installer son système, pas faire un cache disque" ? Il faut plus gros ?

non, c'est juste qu'un particulier, en général, quand il achète un ssd, il s'en sert pour installer son système.

• le cache ram est utile en lecture mais les écritures doivent passer par le disque dur
• le ssd persiste les données même en cas d'arrêt du système

Je suis d'accord sur ces 2 points, même si pour moi c'est le même problème, il FAUT passer par le disque pour ne pas perdre de données en cas de plantage/arrêt du système.

• à 150€ la barette de 8GB de RAM qualité serveur, 128GB couteront dans les 2400€; alors qu'un SSD 128GB coutera moins de 400€.

Celui là un peu moins, des machines avec beaucoup de ram, on en trouve pas si cher.
Chez nous les machines de renouvellement actuelles ont 192 Go de Ram, et on ne les paye pas "énormément" cher, en tous cas, si la ram seule coutait 2400 €, j'imagine même pas les machines complètes !!!

Et puis pour ceux qui veulent vraiment des performances en lecture, je pense qu'ils ont les moyens de mettre ce genre de prix pour avoir de la mémoire.
Pour les autres, un ssd de 128 Go c'est pour installer son système, pas faire un cache disque.

Debian/Testing a pas mal d'inconvénients en tant que distrib rolling release

C'est surtout que debian n'est pas une rolling release.
J'ai d'ailleurs un bug qui me fait bien chier en ce moment dans qt script est qui est déjà corrigé dans la 4.8.3, mais il ne sera pas backporté car pas critique, et je dois vivre avec jusqu'à la sortie de la release :/
Au final je vais certainement recompiler qt en y incorporant le fix.

j'avais compris :D

Mais comme maclag, je pense que pour les gens, "notre technologie est brevetée" ça veut dire "On a eu une super idée que personne d'autre n'a eu et que vous ne pourrez avoir que chez nous, en plus, ça marche trop d'la balle, j'vous jure !!"

Faut espérer que les mentalités changent avec les récent abus abusivement abusifs du système de brevetage.

C'est vrai que je connais plutôt mal le problème des écritures. N'hésite pas à me reprendre si je dis des bêtises.

Je suppose qu'on ne peut pas se permettre de garder trop longtemps en cache mémoire seulement une page à écrire, pour éviter une perte de données en cas de plantage ou coupure de courant.
Il peut y avoir aussi d'autres problèmes difficiles à gérer, comme quand le disque est presque plein, et qu'au moment de l'écriture effective, on trouve plusieurs secteurs défectueux, dans ce cas là, on n'est plus en mesure de tout écrire, alors qu'on a annoncé que c'était le cas.

Je suppose donc que dans ce cas, un cache SSD fait office de cache disque non volatile et peut-être pertinent (quoi que je ne voit pas comment il peut aider dans le cas du disque "plein par surprise" comme diraient les suèdois)

ça dépends pour qui, moi ça a plutôt tendence à me faire fuir…

j'aimerai bien une source fiable de ce truc, car de plus en plus, je lis des document et rapport qui disent le contraire, que la population n'était pas esclave comme l'imaginaire collectif l'imagine, mais que les condition étaient très clémentes (pour l'époque), que les gens recevaient des soins (on a reconnus des soins dentaires, des cicatrices de fractures soignées dnas les ossements) et que ça n'était pas de l'esclavage mais bien du travail.

Maintenant comme je m'y intéresse assez peu, je ne prends pas forcément le temps de me documenter en profondeur et je ne sias pas trop qui a raison.

entrent dans l’atmosphère à environ 30 000 km/h (mach 24)

Le mach étant la vitesse de propagation des ondes mécaniques dans un milieu donné, à l'entrée dans l'atmosphère, la desité étant très très faible, les ondes se déplacent très très lentement voir pas du tout, donc dire que 30 000 km/h vaut mach 24 est partiellement faux (et complètement faux dans le cas de l'entrée dans l'atmosphère), car il n'est pas précisé mach 24 dans quel milieu ;)

Le cache disque en mémoire étant déjà présent et les mémoire de plus en plus grande.
Au boulot (j'ai une grosse machine), absolument tous mes accès disques sont en cache, il n'y a que les premiers accès qui sont longs.
Quel est donc l'intérêt de ce genre de solutions ?
Pour les serveurs qui gèrent énormément de requetes sur de très très grosses bases de données ?
On ne peut pas simplement leur mettre plus de mémoire ? Le coût n'est pas si exorbitant au final, et la différence entre un accès en cache mémoire et un en cache ssd est quand même énorme !
Ou alors pour des machines un peu plus anciennes qui ne gèrent pas de grosses quantités de mémoire ?

j'ai hésité, mais comme il parlait de "une ou plusieurs barres de chocolat", alors je suis resté sur deux

Et pis tant pis pour les moins sâges, c'est eux qui rigolent pas, pas moi ! En tant que bon geek habitué aux plaisirs solitaires, si je me fait rire tout seul, ça me suffit \o/

Tu mélanges tout toi aussi !!!
Le pain au chocolat, c'est quand il y a une barre de chocolat. Quand il y en a deux, c'est la chocolatine !!
C'est simple, suffit de savoir compter jusqu'à dix !

En fait, les décorations sont bien gérées par le client mais une fois que le client détecte qu'on a cliqué sur la barre des titres, il dit à Weston de mettre l'application en "mode de déplacement" et c'est le serveur Weston qui va ensuite déplacer la fenêtre de manière autonome quand l'utilisateur bouge la souris jusqu'à ce que l'utilisateur relâche la souris.

De ce que tu dis là, en effet ça evite qu'une appli lente à répondre fasse saccader le mouvement de la fenêtre, mais elle doit quand même effectuer le changement d'état (passe en mode déplacement)
Donc si elle ne réagi pas au click de souris, pas de déplacement. Et si elle ne réagi pas au lacher de souris ? Déplacement perpétuel ou c'est wayland/weston/walibi qui détecte ça ?

Les projets libres s'en foutant complétement, vu qu'ils en ont jamais rien a foutre de tout casser en temps normal….

C'est un autre problème ça.
La publication des soucis de sécurité est faite avant tout pour que les utilisateurs se protègents, coupent le service, mettrent en place des contournements, …
S'ils s'en foutaient vraiment, ils ne publieraient rien, c'est plus rapide et moins chiant, surtout quand on a peu d'utilisateurs et qu'en plus ils ne payent pas.

Elle est directement visible car tu affiches en premier le nom du fichier dans ton interface.
Si tu décides de mettre cette info ailleurs, tu peux très bien avoir une interface qui affiche cette information aussi.

Au risque de te décevoir, cette version de Debian était sortie… Et ça a duré 2 ans.

Effectivement, je viens de lire ça :
"For the stable distribution (etch), these problems have been fixed in
version 0.9.8c-4etch3."
J'étais pourtant persuadé que ça n'avait été présent que dans la version testing, j'ai même déjà fait exactement la même remarque dans un autre commentaire et personne n'a relevé !

Mais je ne vois toujours pas en quoi ça change le problème de culture du développement dont je parle. Je le redis encore une fois, ça n'étais absolument pas le point important de ma réponse.

Et tu critiques différemment suivant que c'est libre ou pas (c'est pris en compte alors que ça n'a rien à voir avec le sujet).

Bah encore heureux, comme toi tu ne critiques pas de la même façon une tarte au citron de chez ton boulanger d'un steak frites du marchant de sandwichs de la grande rue !
Chaque projet est différent, les personnes qui le composent, ses objectifs, l'importance que tu lui donnes, et des tas d'autres choses, donc je ne les critique pas pareil, tu ne les critiques pas pareil, personne ne les critique pareil…

Prendre un exemple d'un problème corrigé depuis des lustres, c'est juste démonstratif du manque de vrais arguments.

Je te le redis, l'exemple est symptômatique d'une façon de faire !
Debian a vu le problème, c'est un problème ultra grave, ils ont réagi au quart de tour, ont publié les erreurs et la façon de les corriger.
Des soucis de sécurités sont trouvés régulièrement dans windows, comme dans tous projets libres, et dans windows, comme dans certains projets libres, leur façon de les gérer est souvent merdique, lente. Ils sont publiés seulement par la pression des utilisateur qui comparent avec la transparence des façons de faire des autres, sinon tu pourrais toujours de toucher la nouille pour avoir des infos…
Et ça, c'est pourri, ça fait partie de la culture de développement du projet, et il faut énormément de temps pour faire bouger les lignes sur ce genre de choses !
C'est toi là qui manque de vrais arguments alors qui pointe ce qui tu as envie dans mon post pour y répondre facilement !