freem a écrit 5059 commentaires

La liste n'est pas bien formaté

formatée.

Je suis à la fois d'accord et pas d'accord.

Je te rejoins sur le fait que les bureaux multiples, c'est franchement bof sur un wm classique. Par contre, sur un wm en tuile, c'est juste le pied, je pense que le fait qu'un bureau (enfin, workspace dans la terminologie d'i3) ne soit que sur un seul écran aide énormément. Ainsi que le fait que se déplacer par clavier d'un workspace à l'autre téléporte la souris dans le workspace cible, ce qui aide terriblement avec un total de presque 4000 pixels!

Sinon, l'autre utilité c'est de masquer très vite les fenêtres not safe for work :p

Si je dois dire exactement ce que je pense, ok.

Pour moi, le C est effectivement trop utilisé, et dans la plupart des cas les développeurs y gagneraient à utiliser C++ qui, jusqu'à ce que j'aie la preuve du contraire, peut faire les mêmes choses à bas niveau, mais en plus permets de les encapsuler de façon à ne pas risquer d'oublier un delete free.
L'excuse de la gestion manuelle de la mémoire est un faux problème, en C++ il est rare d'avoir réellement besoin de le faire: les smart pointers et la RAII sont là pour ça. En plus, contrairement à des langages utilisant un GC, c'est bien plus simple de savoir quand un objet va être libéré, et donc quand il finira par libérer les ressources dont il à besoin: accès fichier, connexion à une base de données et connexion à un port sont les premières choses qui me viennent à l'esprit, et je ne connaît pas des masses de programmes qui ne manipulent rien de tout ça.
Les garbages collectors devraient commencer par se collecter eux-mêmes franchement.
Pour le C++, je peux aussi citer les templates qui sont extrêmement puissants. La dernière fois que j'ai eu à toucher du Java ou du C#, il n'était pas possible de faire de la spécialisation partielle, entres autres (je parle d'avant 2011). Pourtant, ça simplifie la vie des devs.

L'un des problèmes par contre du C++, c'est que dès lors que l'on doit exposer des classes et des méthodes l'ABI n'est plus garantie, donc on s'expose à des emmerdes si on à pas le même compilo dans la même version (du coup la méthode habituelle est d'utiliser le sous-ensemble C: des structs qui n'intègrent aucune méthode qui sont gérées par des fonctions. Du C quoi.).

Donc, le C à bel et bien un avantage sur certains langages de plus niveau.
Ce même avantage reviens quand on doit faire interagir des applications écrites dans des langages différents: le Java, le C++, le C#, et probablement d'autres plus obscurs savent tous charger des bibliothèques codées en C.

Je vais continuer sur python (histoire de me faire encore plus moinsser), et dire que je trouve néfaste le fait qu'un langage soit si dépendant de sa version. Sur la machine de laquelle j'écris, j'ai 2 versions de python. Par contre, une seule version de libc. Et manifestement, j'ai pas loin d'une centaine de Mo de dépendance pythonique. Oui, je sais, l'espace mémoire c'est pas cher, mais moi, je me dit que 100Mo * 9, c'est déjà près d'un Go. Pourquoi par 9? Parce qu'il y à 9 PC de bureau à mon taf. 1 Go, c'est vrai, ce n'est rien… mais je suis encore à l'échelle d'une petite entreprise.
Dans le cas de perl, c'est moins pire, seulement 50Mo, mais il faut dire que perl semble beaucoup moins dépendant de la version du langage. Moins utilisé aussi. On peut supposer que ce serait dans les 100Mo aussi s'il y avait 2 versions…

Si l'ensemble des gens de ma boîte tournaient sur Debian, configuré pour être minimaliste (oui, parce que les 150Mo, c'est sur une config que j'essaie de garder minimaliste, je pense que si j'avais un DE monolithique type KDE ou gnome, ce serait très probablement plus gros…) on parlerait alors de 1.5Go, à la louche.
À l'heure ou l'on parle d'économie d'énergie, c'est tout de même dommage, non? Parce que les libs et interpréteurs, il faut les charger en RAM, pour que ça serve. Et quand on charge un programme interprété, il faut stocker la forme binaire optimisée, en RAM également. Hors, la RAM, ça consomme de l'énergie.
J'ai vu une étude qui montrait que le coût en énergie des machine est de moins en moins négligeable face à leur coût d'achat. Certes, c'est dû au matos de plus en plus performant, mais pourquoi as-t-on besoin de matos de plus en plus performant?

Alors, ok, je te rejoins sur le fait que 90% des applications incluant une interface graphique n'ont aucun intérêt particulier à être codées en C. Par contre, je ne vois pas ce qui leur interdirait d'être écrites en C.

Quant à l'argument "oui mais les débutants savent pas faire proprement".
Désolé, cet argument est juste l'un des pires qui existe: si on commence à jauger les langages à l'aune des cochonneries que font les débutants, alors je doute qu'il existe un seul langage correct: je défie quiconque de me prouver que pour un langage donné il est impossible de faire du code de plus de 1000 lignes qui soit crade (je dirait même que moins un langage est typé, plus il est facile d'écrire de la merde, le code php que j'ai devant les yeux au taf le montre bien).

Perso mon but est pas de basher un type en particulier, je ne savais même pas que c'était un gars seul.

Je n'ai fait que dire le fait que je sois en général confus après la lecture d'un des benchmark, et il est possible que cette confusion vienne de mon manque de connaissance des sujets.

Reste que pour moi, Office c'est une parenthèse dans l'histoire de l'humanité.

Je ne vois pas l'avantage de coder des applications non-système en C.

Tout à fait. Il est inutile d'avoir des logiciels de rendu --tels que blender ou the gimp-- performants après tout. (bon ok, dans le cas de blender il y à aussi du C++ à en croire wikipedia)

C'est de l'humour?

8Go avec seven, eclipse et des navigateurs internet mainstream, ça ne me surprend pas que ce soit insuffisant…

s/demenu/dmenu/

demenu c'est un suckless tools :)

Malheureusement, ça ne s'est pas vraiment amélioré sous notre OS préféré.

Hum, l'OS, ou les DEs populaires? Mes machines n'utilisent pas plus de 256Mio de ram au démarrage avec client mail démarré et divers terminaux… mais je n'utilise pas les mêmes logiciels que la moyenne.

des langages de programmation et de leurs dernières moutures (exemples C++: templates, méthodes virtuelles, opérateur .* et j'en passe).

Pour les templates, sois rassuré, ça n'impacte que la machine du dev. Pour le reste, ça dépend de l'archi du soft et de comment sont utilisées les features, mais à titre de rappel, GCC qui est (était en fait) codé en pur C est vachement plus lent à compiler que clang, avec engorgement de RAM fourni (potentiellement dû à l'usage d'un garbage collector? J'avais vu ça sur un article d'un de leurs dev qui parlait de migrer certains modules en C++, et je ne serai pas étonné que ce soit une des causes de l'amélioration des perfs de GCC depuis l'arrivée d'un concurrent…)

Enfin, en réalité, je suis globalement d'accord avec ton propos, on à beau dire qu'un programme interprété n'a de coût qu'a son premier lancement, entres autres autres, je reste très sceptique à ce sujet, et je trouve que ce n'est pas sain de garder des tonnes de softs pré-compilés en cache et au code source dans le disque. Certes, les ressources, c'est pas cher, mais bon… multiplier les langages implique de multiplier les frameworks (bash, perl, python en même temps sont habituels de nos jours, et ont des binding pour divers frameworks), ce qui à mon avis cause également un gâchis des ressources.

Mais bon, la solution à tout ça, c'est de choisir ses logiciels en fonction des technologies qu'ils utilisent, et pour ça, debtags est très utile aux debianistes.
Autre chose, plutôt qu'utiliser des logiciels hype, utiliser des logiciels fonctionnels, mais bon, c'est sûr, ça implique de pas avoir de coins arrondis, ni même parfois, horreur, de fonds d'écran.
Pour ça, il faut par contre accepter de se souvenir qu'on utilise les logiciels, pas leur esthétique. Être utilisable et intuitif ne signifie pas être joli, c'est même souvent le contraire j'ai remarqué (je ne dis pas que c'est une fatalité ceci dit).

1: Fragmentation

A ce sujet, et au sujet des logs, j'imagine que choisir un "usage" pertinent (taille de blocs) peut aider? par exemple, dans le cas des logs, utiliser des blocs les plus grands possibles pour /var/log (/var tout court pour ma part, sachant qu'avec les caches de paquets et autres joyeusetés les fichiers ne sont pas super petits) permets de réduire la fragmentation ce me semble.

Je crois (pas sûr du tout) que extfs ou je ne sais quoi, le truc qui se lance automatiquement tous les N montages, défragmente les partitions de type EXT.

Donc, oui, du ext ça fragmente et ce n'est pas nouveau. Juste moins que NTFS et sans commune mesure avec FAT, mais comme pour ces deux concurrents, il est possible de défragmenter, j'en suis presque sûr.

C'est quoi?
Sur le web, une recherche parle beaucoup de livrets A, de trucs bancaires quoi. Donc, c'est quoi, un livret bleu dans ce contexte? Je connaissais les livres blancs, mais bon…

Euh, non, on apprend dans les bench que GCC est plus lent qu'avant en compilation sans LTO alors qu'il est vachement plus rapide avec LTO qu'avant. Autrement dit, que GCC s'améliore face à son concurrent.
J'ai aussi dénoté une amélioration non négligeable du score de LLVM sur 181.mcf sans LTO.

Je n'ai pas regardé plus que ça les graphiques basés sur les pourcentages, il faudrait que j'arrive à comprendre ce qu'il signifient pour ça :/

Sinon, personnellement, je trouve les conclusions intéressantes, déjà parce qu'il mets bien dans le contexte, mais aussi parce que j'y ai appris entres autres que LLVM utilise systématiquement les regisres SSE pour des opérations de mouvement mémoire vers mémoire, alors que GCC utilise des registres généraux.
J'admets ne pas être sûr de tout comprendre, hein, et je comprend que certains trouvent ce genre d'info inutiles (peut-être parce qu'ils le savent déjà, ou parce que c'est écrit dans le FM, ou …) mais ça me donne des pointeurs vers de futures recherches.

Mais bon, j'imagine que je suis de ceux qui voient le verre à moitié pleins, et je rejoins le commentaire précédent qui dit que c'est toujours mieux que les bench de phoronix, que je trouve soit moins pertinents, soit moins clairs (dans tous les cas je ne comprend pas l'ensemble, mais dans le cas de ceux de phoronix, j'ai l'impression de nager dans une confusion assez générale à la fin).

Malheureusement, les bloatwares bureautiques sont aussi imposés par des gens bien pensants, il n'y à donc pas que les documents à vocation d'impression.

Pour dire à quel point cet état de fait me les casse, l'analogie que je peux trouver, c'est celui de l'allergie. Pour avoir été allergique "à la poussière", je trouve qu'utiliser un de ces machins est aussi désagréable qu'une nuit dans un lit poussiéreux. Le seul truc bien, c'est que les effets durent moins longtemps une fois quitté l'environnement hostile.

Ça aurait été du foo+=step; figures-toi que je n'aurais pas relevé. La, c'est foo=foo+step; et même si je suis d'accord que dans ce cas, dans ce code, avec ces types, que ce soit en C ou en C++ ça ne change rien au binaire.
Juste, ça change la facilité de lecture du code, et ça montre que l'auteur ne semble pas habitué aux langages héritiers du C (pour faire court, parce qu'ils sont légions et intègrent tous ces raccourcis).

On peut effectivement faire confiance aux compilateurs modernes pour les optimisations. Je dis juste que, en ayant lu rapidement (en diagonale) le source je constate déjà des éléments qui montrent l'absence de compréhension du langage par son auteur.

Sinon, dans l'absolu, l'arithmétique de pointeurs, ce n'est pas pour rendre le code illisible, c'est parce qu'il en résulte une économie dans le nombre d'instructions machine.

Dans le cas d'un index (il arrive que ce soit utile d'utiliser des indexes, je ne dis pas le contraire. Juste, pas ici.):

• Initialisation de l'index (i=0)
• calcul du pointeur final (foo[i])
• déréférencement du pointeur final (bar=foo[i])
• incrémentation de l'index (i++)

Dans le cas d'un pointeur:

• initialisation du pointeur (pi=&foo)
• déréférencement du pointeur (bar=*pi)
• incrémentation du pointeur (pi++)

Une instruction de moins, sur un pointeur, à chaque itération (sachant qu'un extrait du code donne ça: diff = std::abs(mValueFunction[nCapital][nProductivity]-mValueFunctionNew[nCapital][nProductivity]); ==> plus d'un index, et mieux, déréférencements inutiles car doublés…).

Mais bon, on peut toujours écrire du code pourri pour faire un bench, se reposer sur les optimisations du compilo (sachant qu'une optimisation de vitesse peut parfois apporter moins de perfs de vitesse qu'une optim sur l'espace mémoire, et que donc il faut savoir quelle optimisation utiliser en fonction du code…) et ensuite accuser le langage.

Mon point, c'est surtout qu'on ne fait pas de bench dans un langage qu'on ne maîtrise pas, et je n'ai souvenir d'aucun code source dans un langage dérivé de C qui utilise encore le "foo = foo + 1;". Excepté les 1ers codes source que j'aie vus à l'école, mais j'ose espérer que les étudiants ont autre chose à faire que des benchmarks?

C'est simple, je n'ai lu qu'en très rapide ce fichier.

Déjà la remarque des tableaux qui à été faite à plusieurs reprises, mais aussi des choses comme:

• iteration = iteration+1; et ++iteration; c'est pour les chiens?
• for (nCapital = 0;nCapital<nGridCapital;++nCapital)avec nCapital un entier qui sert d'index. Un dev C aurait utilisé une arithmétique de pointeurs, un dev C++ des itérateurs.

Pour les tableaux qui marchent à l'envers (par rapport au langage), on pourrait excuser, ce sont des choses qui peuvent être spécifiques à des langages, mais ça, ce sont des idiosyncrasies de base du langage C++ quand même.

Il faut en avoir de grosses pour oser ensuite dire qu'un langage est plus rapide qu'un autre parce qu'on à bâclé le programme du second, quand même. C'est le seul point pour lequel ce bench mérite "le respect".

Je parlais en shell pur, comme la syntaxe basée sur echo. Avec les calculatrice, je me doute bien que c'est simple, manquerait plus que ça :)

Un mauvais exemple? Au début tu disais que c'est parce que c'est un logiciel, maintenant c'est parce qu'il est proprio… la blague: un logiciel reste un logiciel.

Quant à la différence entre les 3 screenshots, elle est très faible: dans les 2 cas il y a une zone principale, dans laquelle est présente l'information recherchée (que ce soit une discussion ou de la pub, puisque les 3 screenshot ne montrent pas la même fonctionnalité), et une zone secondaire avec liste des contacts.

Que ces choses ne soient pas affichées au même endroit… ne signifie pas que le code source soit très différent.

Je suis curieux de voir la ligne shell pour convertir en binaire, octal, ou hexadécimal, et ce genre de choses me sert énormément.

Mais bon, merci pour le lien, je galère tout le temps quand je dois jouer avec des entiers dans un script..

perso, avant de savoir que certaines personnes préféraient que les lignes ne soient pas vraiment coupées, je croyais que le fait de ne pas les couper était un défaut de l'éditeur qui n'était pas capable de le faire automatiquement pour moi.

Le truc, c'est que quand tu as des coupures artificielles, comme dans la technique que tu utilises, quelqu'un avec des préférences/contraintes différentes des tiennes sera emmerdé.
Exemple simple: personnellement, j'utilise des terminaux avec un gestionnaire de fenêtre en tuiles.
Jusque la, aucun souci, mettons que j'adapte une tuile pour les 80 char de large. Ça marche, c'est automatique. Mais quand je redimensionne ma tuile, et donc l'éditeur dedans, soit je perds de la place parce qu'une partie reste "blanche", soit je perds et de la place, et de la lisibilité parce que la largeur effective de l'éditeur est inférieure à 80, et le wordwrap fait qu'on se retrouve avec des "lignes" composées d'un seul mot. Ou de deux.

Je jouerai un peu avec tw et gq, mais un test rapide me fait penser que ce n'est pas la encore la panacée, même si c'est vrai que ça améliore pas mal.

Fais :set paste avant de coller, puis :set nopaste après.

Ah, pas mal ça! J'adopte.

donc on peut déjà configurer vim pour presque tous ses besoins sans en savoir plus.

C'est à peu près ce que je fais, mais comme tu l'as dit, c'est tellement riche que n'avoir ne serait-ce qu'un aperçu des capacités de vim, ça demande une réelle formation. Alors que pour moi vim n'est qu'un outil me permettant d'écrire du code, j'ai déjà assez de problèmes à essayer de maîtriser mes langages de travail, perso.

Les applis Skype ne sont pas "multiplateformes", il y en a une par OS : Skype for Mac n'a pas le même look que Skype pour Windows 8.

Skype utilise (ou utilisais avant que MS ne rachète) Qt, et si je me souviens bien, Qt inclue des outils pour adapter le look de l'appli au thème du système.

Ça n'a rien à voir avec une appli comme Audacious, qui n'a absolument pas besoin d'avoir le même design partout pour lire plein de formats de musique différents.

Pas mal d'appli multi-plateformes s'intègrent dans leur environnement. Déjà, toutes celles utilisant wxwidgets comme toolkit. En exemple connu, à l'heure actuelle, je citerai code::blocks, ou audacity. Et du fait même du toolkit ( wxwidgets se base sur les toolkits considérés comme natifs. Dans le cas de linux c'est gtk, bien que je sache qu'a un moment des ports Qt et X11 étaient en cours de développement) elles changent de gueule d'un bureau à l'autre. Et ce, sans supprimer de fonctionnalité aux applications.

Dommage, je ne suis pas sûr de pouvoir poser un congé en si peu de temps, ça m'aurait bien intéressé sinon. Et Toulouse, c'est loin.