freem a écrit 5019 commentaires

C'est bien d'avoir de la RAM, oui, c'est sûr.

Maintenant, il n'y à pas que la taille^W capacité qui compte, mais aussi la fréquence. Je me demande si l'accès à la RAM d'un téléphone est aussi rapide que celui à celle d'un PC portable?

Mais on sait pourquoi.

La raison de ne plus utiliser les primitives de X, c'est qu'on veut des coins arrondis, de la transparence, et accessoirement utiliser le GPU pour ça (ce dernier point étant quand même pertinent).
Tout ça, ça implique d'utiliser OpenGL, et donc balancer des buffers pré-calculés au serveur graphique qui se contente de filer les pointeurs au GPU plutôt que de copier N fois ces fameux buffers résulte en simplification du code et amélioration des performances.

En fait, si on pouvait faire un toolkit qui utiliserait l'accélération 2D de Xorg, on pourrait avoir un truc réellement rapide sur le réseau, par contre, qui serait prêt, à l'heure actuelle, à se passer de toutes ces petites icônes, images & co hyper dures à compresser et gourmandes en BP? Qui serait prêt à se passer, en fait, de l'esthétique? (perso, ça me poserait aucun souci vu que je le fais déjà, mais je pense que je fais partie d'une minorité)

En gros, le pourquoi, c'est parce qu'on veut des trucs jolis, adaptés au rendu moderne, alors que X à été conçu à une époque ou l'efficacité primait sur le bling-bling (pour des raisons techniques, notamment).

Maintenant, je viens de me souvenir que, au moins OpenGL 1 (obsolète, je le rappelle) utilise une sorte de pile pour générer l'image. Je ne sais pas (mais alors vraiment pas, je m'y suis intéressé et ai abandonné quand il à été question de tesselation, d'autant que je me suis aperçu un peu trop tard qu'OpenGL 1 était… obsolète, snif, et que je n'ai rien trouvé de clair pour commencer à utiliser ces p***** de shader) s'il serait possible d'imaginer une transparence réseau ou l'appli envoie ce stack sur le réseau, et le PC client le reconstruit… peut-être que ça prendrai moins de BP?

Pas du tout. C'est effectivement possible mais ça reste une opération manuelle.

Bah après, il m'a dit que ça s'était fait tout seul, et je doute qu'il m'ait menti (pour ce que j'en ai à foutre de son windows… et il le sait très bien). Enfin, peu m'importe, les errements des trucs tout jolis qui te bouffent 1 à 2 Go de ram au boot m'intéressent moyennent, j'ai l'intention de rendre mes machines de plus en plus fonctionnelles (de mon point de vue, qui est que la souris est un instrument qui me consomme pas mal de temps de façon régulièrement injustifiée), pas de plus en plus jolies.

Les mainteneurs Debian peuvent très bien le faire avec leurs machines persos. Et franchement, 4Go de RAM, c'est peut-être l'entrée de gamme, mais sérieux, c'est déjà énorme, il n'y à que les super grosses applications qui peuvent bouffer tant à la compilation, et j'ai envie de dire que je ne suis pas sûr que ce soit toujours justifié.

Bon, il faut aussi dire que compiler avec GCC ne doit pas aider, c'est un véritable goinfre ce compilo, et j'ai constaté une diminution drastique de la RAM utilisée en utilisant clang il y à 2 ans (un projet qui faisait swapper à la compilation mon netbook et son unique Go de RAM avec 3 thread me laissait 200Mo utilisables avec clang et 4 thread).

L'ancienne interface (celle d'il y à 1 an) était mieux foutue sur ce point.

Par contre, je ne supporte absolument pas github, (je n'y vais que quand j'y suis contraint) pour diverses raisons, par exemple:

• interface bordélique
• interface lente
• interface inutilisable sans JS

Donc, même si bitbucket n'est pas à la mode, ça reste à l'heure actuelle mon favori. Quitte à avoir une usine à gaz comme github, autant utiliser sourceforge qui offre plus de fonctionnalités (forums, entres autres) et les trucs basés sur savannah semblent figés (bon, on attend mes patchs en même temps).

Accessoirement, bitbucket permets d'avoir 5 dépôt privés, utiles pour des trucs qui n'ont pas d'intérêt pour les autres mais qu'on peut améliorer par pichenette, genre un CV, des config de $HOME, voire pourquoi pas un projet fermé (et la, je prend le risque de me faire pourrir xD).

C'est un peu le béaba du c/c++.

Désolé, je n'ai jamais lu le standard, donc non, pas spécialement le b-a-ba. Oui, je sais que c'était un problème dans mon code, et, si, mon workaround avait résolu le problème. Je ne suis juste plus sûr que c'était exactement ça, peut-être que c'était une fonction inline. Mais c'est sûr que c'était un truc crade, par contre.

Encore une fois, si tu cherches un truc genre i3, tu t'es trompé d'OS.

Bof, je ne l'utilise pas personnellement, je ne fais que constater les ravages autour de moi. Comme je le dis dans un commentaire un poil plus haut, sur une machine vendue avec w8, ça rame de manière affolante, et je n'ai pas vu énormément de soft lancés au boot.
Alors, est-ce moi qui me plante d'OS, ou les constructeurs?

(mais la courbe d'apprentissage comme disent les anglo-saxons est assez frustrante).

Elle l'est moins quand on utilise les raccourcis clavier depuis longtemps, c'est comme ça que j'ai pu montrer comment imprimer à ma mère, notamment. Ils ont eu la décence de pas tous les changer…

C'est surtout tactile-oriented.

Je suis d'accord. Ce n'est donc pas une innovation du bureau puisque le bureau, c'est clavier+périphérique de pointage, pas écran tactile.
D'ailleurs, il semble que maintenant w8 boote sur l'interface classique. Il y a du y avoir une MaJ… (vu chez le frangin)

Hum. Que veux-tu dire par API asynchrone dans ce modèle?
Pour ce qui est de sandbox, j'ai du mal à voir pourquoi ce serait le taf d'un gestionnaire de fenêtre, ça devrait être celui du serveur graphique ou du kernel, non?
Ce sont de vraies questions, pas polémiques (la polémique viens de suite t'inquiètes ;) )

Et pour ce qui est de l'économie de batterie… quand je vois les "performances" de windows 8, je me permets de douter. Je suis allé chez mon frère il y à quelques temps, discuter, et tester HOM&M 6. Bon, que le jeu lui-même galère, c'était pas surprenant.
Mais on à du rebooter pour "nettoyer" la RAM, manifestement les choses ne semblent pas se fermer (selon mon frère) quand on le leur demande.
Les reboots ont bien mis 10 minutes chacun, sur une machine pourtant de moins d'un an, et sur laquelle je n'ai pas constaté de profusion de machins à la con lancés au boot.
Je doute que la batterie tienne bien longtemps sur un OS qui semble aussi chargé.

Alors la nouvelle efficacité du paradigme, je suis assez curieux que tu en dises plus pour le coup, parce qu'avec mon truc ancestral, sur un netbook ben j'en ai pour 30s de boot, moi, et la batterie tenait ses 6 heures d'utilisation vidéo au début.
Et côté ergonomique, c'est une tuerie, modern UI. Dans le mauvais sens du terme, clairement, et pas que selon moi, qui au fond s'en cogne parce que je n'ai pas l'obligation de l'utiliser pour le moment. Et bien sûr, je prie pour qu'il en soit ainsi pour les siècles des siècles (enfin, si je vis encore ^)…

Quant au visuel… non, ce n'est pas "que" le visuel, c'est aussi le contrôle que l'on à sur les fenêtres, et le fait que les fenêtres se placent ou on le souhaite, d'elles-même. Mais, je t'accorde qu'avec certaines applications, c'est pénible, notamment xpaint, gimp en mode multi-fenêtre (ce qui n'est plus obligatoire du coup) et celles qui s'amusent à utiliser des boîtes de dialogue en popup.
D'où très certainement mon attirance relativement récente pour les applications TUI :) en plus, ces applications dans le cas de celles qui sont en ligne de commande s'interface magnifiquement avec les autres, il suffit de piper.

Au sujet de Lennart… je n'ai pas d'opinion, je suis trop nouveau dans l'utilisation de Linux. Je sais ce qui lui est reproché, mais… bah, il à des idées différentes, et les moyens de les implémenter, alors qu'il fasse. S'il faisait vraiment que de la merde, je doute qu'il serait embauché chez Red Hat d'une part, et d'autre part que des distros autres que RHEL et Fedora utiliseraient ses œuvres.
Tu ne me verras pas critiquer un de ses softs à cause de l'auteur, je pense, pas d'ici longtemps. Surtout que je pense sincèrement que des choses comme systemd sont intéressantes, parce qu'elles vont faciliter le contrôle des débutants sur leurs machines. Maintenant, le fait que moi je préfère éviter est pour une autre raison, et c'est pas l'amour de sysvinit, juste que je ne vois pas l'avantage de systemd compte tenu de mon utilisation des dites machines, et que je considère que les divers composants de systemd sont trop inter-dépendants. Maintenant, des applications non portables, il en existe plein, on a jamais tué personne pour ça, il suffit d'en utiliser une autre, mais généralement les autres ont moins de fonctionnalités. C'est une histoire de compromis tout ça.

Oui, bien sûr et heureusement que la modularité est faisable en électronique, sinon on serait tous avec des powerPC à l'heure actuelle, parce qu'IBM/Microsoft n'auraient pas réussi à s'imposer (archi matérielle ouverte, donc machines améliorables par la greffe de composants faits par des tiers, donc réduction des coûts, contrairement aux mac du début, si je ne m'abuse).

Maintenant, je répondais à un commentaire qui disait "si ce n'est que le hardware, il n'y a qu'à le faire". J'ai vu des projets qui essaient de faire des cartes graphiques, d'autres des consoles, et je suis aussi tombé sur des explications pour faire son propre smartphone. Franchement, si quelqu'un sort le-dit smartphone dans la rue, il a intérêt à savoir assumer sa différence, parce qu'on ne parle plus de frigo, mais de congélo industriel à ce niveau la :)

Et dans le cas où l'on veut faire tout le matos en libre, il faut effectivement repartir de zéro, parce que je doute qu'il y ait des composants industrialisés qui soient déjà libres au sens des 4 libertés de RMS ou des DFSG. Quelques interfaces et protocoles, oui, mais le matos proprement dit? M'étonnerait malheureusement.

Et au sujet d'apple, il y à une époque ou ils faisaient tout, de A à Z je crois. Ils ont fini par abandonner pour réduire un peu le coût, et passer d'objets pro à objets de luxe. Maintenant, ils utilisent une archi intel (pour la déclinaison bureau, je parle, hein), comme la plupart des autres j'imagine. En tout cas, jamais vu d'autres archi que de l'x86 sur un PC de bureau.

J'ai plutôt l'impression que la cause d'emmerdes majeures des packageurs, c'est la quasi absence de préoccupation du packaging des dev de KDE (et peut-être des gros projets de manière générale?):

• pas de version stable, chaque nouvelle version ajoute de nouvelles fonctionnalités, et donc bugs
• archives monolithiques même si les sources que ça inclue sont relatives à plusieurs modules distincts

Et un commentaire intéressant du mainteneur Debian:

Not so far ago, discussing something with some upstream (not Qt), he told me "just make -j6 upload and be done". My first reaction was "I wish I could do that". My "most capable" system is a dual core with "just" 4GB of RAM, so I have to resort to swap for being able to build beasts like webkit.

Bon, à priori il y a aussi des problèmes de communication entre les mainteneurs des diverses distro, qu'ils semblent avoir envie de résoudre d'ailleurs…

A noter que certains mainteneurs parlent de problèmes liés au fait que gnome et kde utilisent des versions incompatibles des mêmes lib. Ça, je trouve ça vraiment très, très drôle (je doute que ce soit leur cas, m'enfin…)

Sinon, le seul commentaire au sujet de ffmpeg dans cette discussion, c'est pour dire qu'a cause de problème de licence, c'est plus casse-pied que gstreamer, je n'ai rien noté sur le plan technique.

Tout ceci étant dit, ce sujet est intéressant (celui qui est pointé) pour ceux qui ne comprennent pas vraiment les différences entre les distros (comme moi): pour le coup, vu qu'ils parlent des problèmes et des solutions apportés par les divers systèmes de paquet, je vais enfin pouvoir y voir un poil plus clair dans cette jungle.

La dernière fois que j'ai fait du c++, je n'ai pas réussi à linker un pointeur de fonction vers une fonction compiler avec un compilateur c. Le B.A.-BA. Je sais pas quelle pédanterie il aurait fallu (genre un proxy bien dégueulasse)…

Donnes-nous donc un PoC de ce qui rate, on pourra peut-être t'expliquer le pourquoi du comment?

Ceci dit, je me demande déjà ce que tu appelles lier un pointeur de fonction vers une fonction C… j'ai suffisamment codé en utilisant des lib C et pourtant je n'ai pas souvenir d'avoir eu ce type de problème?

Un truc genre

#include <cstdio>

int hello(int i, float j){puts("hello ");return 0;}
int world(int i, float j){puts("world!");return 0;}

int main(void)
{
  int (* pFoo) (int, float);
  pFoo = hello;
  pFoo(1,0.2);

  pFoo = world;
  pFoo(1,0.2);

  return 0;
}

compile parfaitement et fonctionne sans souci.

Bon, si c'est un souci de linkage, sache que j'ai fait le même genre de trucs avec la SDL 1.2, pour être précis, j'ai utilisé du std::unique_ptr avec SDL_Surface, en lui passant en destructeur la fonction qui remplace le destructeur. Donc, j'ai déjà fait aussi avec un truc compilé par un compilo C.

Le matériel, ça coûte cher, très cher à concevoir, c'est ça le souci.
Là ou un logiciel ne coûte quasiment rien à part du temps, du matériel nécessite d'avoir un véritable laboratoire, avec des composants qui ont un coût matériel.
Il y à aussi les compétences qui ne sont pas les mêmes: j'aurai tendance à dire que l'électronique nécessite des connaissances plus larges que la programmation, puisqu'en programmation on peut se reposer sur des bibliothèques qui nous évitent de nous taper le bas niveau: quand je code, disons, un casse-brique, je n'en ai rien à rien à faire de l'impédance des hauts-parleurs, ni de la fréquence du bus PCIe.

En électronique, tu dois (si ça marche de la même façon que ce que j'ai fait en STI électronique il y à 10 ans, bien sûr), commencer par étudier ton circuit dans un monde idéal pour avoir des calculs/formules qui tiennent à peu près la route, puis vérifier que le comportement ne posera pas de problèmes avec les marges d'erreur des composants que tu utilises (oui, parce qu'un condensateur, même si la théorie dit qu'il n'a qu'une capacité, en fait il à aussi une impédance, et ça impacte. Et même si un transistor en régime saturé bascule théoriquement d'un état à l'autre de façon instantanée, dans la pratique c'est complètement faux… entres autres.). Ces phases sont plus complexes que dans le cas d'un logiciel classique (on parle bien des bureaux là, hein?) ou il n'y à pas besoin d'être calé en maths (niveau seconde, à peu près: équation du 2nd degré quoi, et encore).
Bien sûr, une fois les calculs faits, en espérant ne pas s'être planté, il faut prototyper, histoire de tester. Là, il y à un premier coût en matos bien réel, qui n'existe pas en dev. Pire, si on s'est planté, on risque de cramer quelques composants.
Une fois cette étape passée, on à un prototype, l'équivalent d'une version debug d'un soft. C'est à dire un truc qui est gros, moyennement voire peu performant, et pas beau.
Il faut donc encore industrialiser tout ça, et je dois t'avouer: je n'ai aucune idée du coût que ça peut représenter, mais je doute que n'importe qui peut se le permettre.

Bien sûr, dans le cas d'apple, ils ne s'arrêtent pas là: une fois le matos fait, ils font également les pilotes… logiciels, qui ne sont pas non plus aussi simples à faire que des logiciels de bureau (j'insiste sur le "de bureau") j'imagine.

Le monde du libre, malgré quelques essais plus ou moins concluants (j'ai lu des doc sur une carte graphique il y à quelques mois), ne peut pas vraiment se payer un tel investissement, et même si c'était possible à cause de la faible échelle de production, ça coûterait nettement plus cher que du matos apple, pour des perfs ridicules (à cause du fait que le matos efficace ça coûte plus cher, et que des électroniciens dans leurs garages ne pourrons pas faire aussi bien qu'une horde d'ingénieurs spécialisés dans des labos de pointe).

Donc, pour le "pas trop compliqué" tu repasseras. Le matos, c'est bien ce qu'il y à de plus coûteux et de plus cher à développer amha. Et je n'ai bien sûr pas abordé la question des brevets…

simplement parce que la notion de binaire persistant n'existe pas en java.

J'aurai dis que c'est parce qu'en Java, il n'y à qu'une machine, une API, et un seul compilo (le tout, de référence, hein, je suis au courant qu'il existe des clones, mais l'interop est-elle si parfaite dans les faits? J'en sais rien…) en fait, alors que pour C++, il y à une pléthore de machines, une chiée d'OS différents qui impactent, et une flopée de compilos.
Forcément, ça rend les choses moins simples.

Je comprends pas, si gtk a eut le soutient de tout les gros acteurs, et est en c, c'est que l'abi du cpp pue (même aujourd'hui).

Pas de tous les gros acteurs, quand même, au moins nokia à soutenu Qt, au point de l'acheter.
Sinon, WxWidgets, même si je sais que ce n'est pas apprécié ici, à été utilisé par google (en version 2.9, je n'arrive pas à retrouver le lien en moins de 60s, mais si tu insistes, j'essaierais plus fort).
Bref, il n'y à pas que GTK, loin de là et heureusement.

Et pour ce qui est de l'ABI du C++, oui, c'est sûr, c'est moche, mais il y à des solutions, un peu plus bas un commentaire parle de pimpl. Je me suis aussi amusé à faire une archi de plug-in un jour, et donc me suis pas mal renseigné. Certes, c'est la merde, c'est clair, mais on peut contourner.

Si java a eut du succès c'est sûrement pas grâce aux qualité du c++.

En effet, Java est bien plus simple à maîtriser que C++, ce qui fait qu'il est intéressant pour pas mal de monde. Il y à aussi une grande quantité de dev Java, contrairement au C++.
Ce genre de choses jouent.

Qt utilise des pointeurs vers des struct pour masquer les évolutions de la structure interne et sauver son ABI.

Effectivement, c'est une des solutions utilisées pour contourner le problème.

e ne peux toujours pas prétendre connaitre le c++ globalement sur toutes les plateformes, je ne connais bien que le sous ensemble de ce qu'en fait Qt.

Je suis d'accord, C++ est un langage réellement riche, ce qui peut faire peur. Mais personne n'est obligé d'utiliser C++ au complet, non plus.
Dis-moi, est-ce plus simple d'optimiser la charge CPU en C qu'en C++? Et si oui, pourquoi? Je suis réellement intéressé par ta réponse pour le coup.

Aieuuuu…. la tuile de w8? Une innovation?

Moi, j'appelle ça une copie avec 10 ans de retard, mais bon… les twm sous linux, ça existe depuis perpette, hein. Je veux bien, à la rigueur, accepter le fait qu'ils aient fait un truc plus user-friendly, mais pas plus.
D'ailleurs, même dans windows, les tuiles existent plus ou moins depuis perpette, c'est juste que, bah, personne ne s'en sert (faut dire que c'est bien moins automatique qu'un wm full-tiling aussi).

Quand j'ai vu w8, et son système de tuile, je me suis dit que ça allait peut-être pas être si mal, j'ai même défendu ce truc à diverses reprises. Puis, j'en ai testé un dans je ne sais quel magasin. Et là, ben… changé d'opinion, genre changement radical.

Ça bouffe de la ressource à bloc, ce n'est pas aussi pratique que ça en à l'air, les icônes (puisque ce système reste mouse-oriented, elles sont importantes. À moins qu'il soit possible d'en fait un keyboard-oriented, mais j'en serais très surpris) absolument non évocatrices.
Je me souviens avoir essayé d'imprimer un truc sur la machine de ma mère (à sa demande), et ne m'en être sorti que parce qu'ils ont eu le bon goût de ne pas changer les raccourcis clavier depuis 20 ans.

Je ne parlerai même pas du fait qu'une interface tuilée, avec un seul workspace, c'est juste un wm castré. Enfin, là, y'a 2 workspace, pour être précis: un en tuile, un en stack. Youpi, mais non.

Mais mon opinion viens certainement du fait que j'utilise un wm réellement orienté vers les tuiles. Et un peu aussi vers les poweruser, je suppose. Je me demande ce que ça ferait si on collait un décorateur de fenêtres sur i3 d'ailleurs.

Et je suis obligé de pertinenter… mais surtout parce que je sais qu'un root sous linux peut péter le système sans le moindre souci, et ironiquement, j'ai envie de dire que ce n'est pas si mal: le système laisse son maître faire ce qu'il veut.
Mais effectivement, ce n'est pas user-proof.

Par rapport à l'auto-destruction de windows, je suppose que mes standards sont assez anciens, mais… j'ai encore récemment entendu parler de MaJ foireuses sur un w8.
Et quand je parle d'autodestruction, je parle d'une destruction sans action de la part de l'utilisateur, chose qui m'est arrivée tant de fois que je ne pourrais pas te dire combien. Mais, encore une fois, tant mieux si ça s'est amélioré sur les systèmes plus récents.

Tu as omis la réputation historique auprès des graphistes, je pense. Ils ont eu une base d'utilisateurs prêts à raquer à mort (milieu professionnel) lié au fait que, si je ne m'abuse, les MAC étaient les premières machines capables d'avoir un rendu à l'écran très proche du rendu imprimé.
Je gage d'ailleurs que c'est pour ça qu'ils ont développé leur réputation de truc cool: on vend pas à un graphiste un truc qui à une sale gueule, j'imagine.

C'est pas comme s'ils connaissaient réellement windows, de toute façon. Ou alors tu évolues dans un environnement 'achement plus savant que le mien…

GTK… tiens, je vais marcher dedans, pour le fun.

Me semblait que si GTK est plus utilisé que Qt, c'est parce qu'à l'origine, Qt n'était totalement libre. Les deux semblent plus ou moins autant utilisés en C++, au pifomètre.

Depuis 1992 on reproche les mêmes choses encore et encore au c++

Marrant, je pense qu'en fait, le premier standard (qui est de 98) à dû résoudre pas mal de problèmes, par exemple les soucis de compatibilité entre les compilo (du moins ceux qui acceptent de respecter les standards).

Les nouvelles normes foutent la merde? Je ne pense pas, honnêtement, je pense même que c'est tout le contraire.
Par exemple, si je prend C++11:
* std::array permets d'utiliser les algo standards avec des tableaux à dimension fixe, et donc de ne pas réinventer la roue. Ce n'est pas une mauvaise chose pour moi.
* std::unique_ptr, uniquement possible grâce à la move semantic, permets de lutter contre les memory leaks en augmentant la garantie qu'un seul propriétaire contrôle un espace mémoire (on peut contourner, comme toujours en C++, et je parie que cette possibilité est conservée du fait qu'on doive interagir avec du C…).
* for( auto i : foo ){ i*=10; }, c'est quand même vachement plus lisible (et sûr) que les alternatives plus anciennes for( int i = 0; i < foo.size(); ++i ){ foo[i]*=10; } ou for( std::vector<int>::iterator it = foo.begin(); it != foo.end(); ++it ){ *it*=10; } non?

Ça, c'est pour les critiques sur les nouvelles normes, mais pour être juste, je me dois de mentionner une fonctionnalité de C++03 (ou 98?) que seul commeau à implémenté, conseillant fortement aux autres dev de compilo de ne pas le faire, parce que ça n'apporte au final rien, semble-t-il. Quelques recherches devraient pouvoir en dire plus.

Maintenant, dire que C++ c'est de la merde contre le C… allez, je marche encore :)

Ça me fait assez sourire quand je vois des gens dire que C++ c'est de la merde comparé au C, en fait. Il suffit de lire du code C pour comprendre ce que C++ à ajouté.
La RAII permets de rendre un code bien plus maintenable et sûr, et les templates ou les fonctions inline permettent de s'affranchir en grande partie des macros, ce qui évite pas mal d'emmerdes.

Avant, les jeux, comme quake par exemple, étaient stables. Ils étaient codés en C. Il faut dire que, les malloc y étaient rares, tous les tableaux étant statiquement alloués, donc les problèmes de mémoire simples à éviter.
Ceci dit, j'ai quelques souvenirs de jeux pour lesquels le dépassement de buffer est simple à causer. En même temps, c'est logique: en C, il faut vérifier le retour de la moindre fonction, manuellement, pour être sûr que tout s'est passé comme prévu.
En C++, et dans tous les langages évolués, la mécanique des exceptions permets de s'affranchir de ce problème. Mais ici, l'avantage du C++ sur d'autres langages, c'est qu'on peut s'affranchir de ces fameuses exceptions.

Et quand on lit un code source C qui utilise de manière intensive de la construction de chaînes de caractères, quelle joie que de voir des buffer alloués avec des tailles impressionnantes, et ensuite une succession de strcat, parce que strcpy( foo, bar ); strcat( foo, "world" ); c'est vrai que c'est tellement plus lisible que foo += bar + "world";.

Je vais m'arrêter là, je pense. Je veux bien que l'on compare C++ avec Java, C# ou d'autres, mais avec le C… soyons sérieux un instant, le seul avantage que je puisse voir du C sur C++ réside de son ABI stable en toutes circonstances (utile pour les plugins).

Dans le cas du C++, l'ABI n'est stable que si l'on n'utilise pas de méthodes virtuelles, voire si l'on utilise des structures pures. En d'autres mots, si on se restreint à des fonctionnalités C.
Ah, non, il y a aussi un cas ou j'ai eu un comportement différent selon les compilos, mais il faut avouer que j'avais cherché la merde, et le workaround était relativement simple.
Ça, ça bug: foo( bar[++i], bar[++i], bar[++i] ); avec VS2008 "i" faut la même valeur à chaque fois, donc la même valeur est utilisée dans les 3 arguments, contrairement à ce que GCC fait. Et les deux comportements semblent être standards, pour une question d'optimisation. Pour l'info, le workaround était, de mémoire, ceci: foo( (bar[++i]), (bar[++i]), (bar[++i]) );.
Mais c'était une construction sale, qui n'avait pour unique but que celui de réduire encore un peu le nombre de lignes de code d'une encapsulation que j'avais fait autour d'une API sur laquelle je n'avais aucun contrôle et qui sans ça demandait de répéter les informations jusqu'à 3 fois, dans 3 fonctions différentes… (powerbuilder, vous connaissez?).

Le meilleur moyen de communication que je connaisse, ça reste d'aller dans les bar et les pubs.

Il y à aussi une technique pour invoquer les gens chez soi: servir l'apéro.

essaye d'ouvrir les fichiers attachés dans ce document (notamment les PDF/ZIP) avec n'importe quelle suite office (libre ou pas) sous Linux,

Je viens d'essayer avec Microsoft Office 2010 sous wine (donc, bien sous Linux) et ça marche je pense.
Quand tu utilises un format spécifique à un logiciel, il est logique qu'il faille utiliser le logiciel en question pour ouvrir le fichier…

Bref, dire que Linux est "prêt" n'est vrai qu'au cas par cas

Je suis d'accord.
Ceci étant dit, c'est la même chose pour Windows: la lenteur à toute épreuve, la faculté d'auto-destruction, l'empêchement de bidouiller en rond (oui, ça, c'est pas pour Mme Michu, mais dans tes arguments aussi, il y avait des trucs de geek), le gestionnaire de fenêtre tout sauf efficace, tout cela ne fonctionne que tant bien que mal dès lors que l'on à une machine qui n'est pas hyper performante.
Si on prend une machine de 10 ans d'âge, Windows (je parle d'un truc encore maintenu) n'est jamais prêt, alors que si on prend Debian, je la fait tourner avec bonheur sur une bécane "design for Windows Millenium". Une Debian stable, bien entendu.

Bref, dire que Windows est "prêt" n'est vrai qu'au cas par cas :) et je ne parle pas du fait que je ne connaisse aucun Microsoft Office qui sache ouvrir correctement un fichier de LO ;)

Ah, au sujet de MS Office, j'ai une anecdote. Figures-toi qu'il y à 5 ans, j'ai été obligé d'utiliser gnumeric pour pouvoir ouvrir correctement un fichier excel, ce dernier étant incapable de gérer correctement des formules qu'il avait générées lui-même (via l'outil interactif). La raison, c'est que l'éditeur de formules de ce truc n'était pas capable d'afficher (mais il les traitait puisque la formule fonctionnait) plus de 1024 caractères.
Comme quoi… les alternatives à MSO sont parfois plus efficaces que MSO sur le format MSO.

Je ne suis pas d'accord. Elle ne pourrait s'en balancer que si elle s'en apercevait, et je doute que ce soit le cas. Après tout, on parle bien de la personne qui utilise quotidiennement IE6 ou IE7?

Exact, je l'avais oubliée, mais faut dire qu'on s'y fait vite :)

+1 pour la résistance au changement. Il s'agit même d'une des facette du métier de chef de projet, que de lutter contre ça (selon des cours que j'ai eu).

Sinon… pour les innovations du bureau, de l'environnement graphique & co.
L'OP à cité un et un seul contre exemple, alors je vais me permettre de compléter:

• utiliser une touche pour déplacer et redimensionner les fenêtre sans s'emmerder à essayer de choper un coin (qui, quand il est arrondi, ne facilite pas les choses).
• les bureaux virtuels.
• ENFIN un usage pour la touche œ.
• ENFIN une solution SIMPLE pour taper des trucs comme: ÀÇÉÈÊ…
• les bureaux 3D, les vrais. Compiz-fusion, ça existe depuis bien longtemps, et les sélecteurs de fenêtres apportaient vraiment des choses utiles. Et pour les gens qui aiment ça, on pouvait transformer un bureau fonctionnel en bureau tape-à-l'œil.

Ça, c'est pour les bureaux classiques utilisables par les non geeks. Hé oui. pendant ce temps, Microsoft:

• enlève la possibilité de disposer ses fenêtres en mosaïques (faisable sous XP de la manière suivante: cliquer un bouton de fenêtre de la barre des tâches, appuyer sur la touche contrôle et cliquer sur une autre. Répéter cette étape jusqu'à avoir sélectionné toutes les fenêtres voulues, puis clic droit sur l'un des boutons et… lisez.). Idem, ce n'était pas difficile à utiliser, et surtout bien pratique.

Maintenant, passons aux fonctionnalités pour les "geeks" (j'ajouterai bien des guillemets mais ça deviendrai illisible): tiling window managers.
Je crois avoir lu que kwin supportait ce type de fonctionnalités à un moment, même sans utiliser un WM spécialisé. Franchement, les outils spécialisés se disent pour les geeks, mais quand on voit la difficulté d'utiliser i3… à mon avis c'est surtout parce que les dev ne veulent pas de trucs bling bling ni être emmerdés à devoir faire de l'assistance pour zombies.

Bref, non, ce n'est pas à cause de la facilité d'utiliser un truc pré-installé que seul Windows est prêt pour le bureau, mais à cause du fait que les habitudes ont la peau dure, très dure. Je connais tant de gens qui disent qu'il est compliqué d'installer un truc sous linux alors que sous Windows, c'est si "simple"!!

L'idée est fun, à voir comment ça va évoluer. Bon courage en tout cas.