Awesome 3.2, et c’est de nouveau «awesome»!
J’étais resté sur un billet faisant de la mauvaise pub à awesome 3.0. Je vais aujourd’hui revoir ma position. Pour les raisons que j’avais données j’étais resté sur awesome 2.x, pas le temps de trouver un autre WM.
Il y a deux jours, je me suis enfin décidé à migrer vers awesome 3.2, en me disant que les choses seraient peut-être un peu plus abouties que dans awesome 3.0. Et c’est le cas. Il y a des plus et des moins concernant awesome 3.x, ça c’est clair, mais je ne pense pas revenir en arrière. Voilà donc mes impressions.
Les plus :
- Une documentation plus complète, notament grâce au wiki;
- Une liberté dans la configuration très appréciable;
- La possibilité de lier la configuration graphique et le script de mise à jour de la bar de status que l’on peut programmer en Lua grâce aux hooks;
- La possibilité d’écrire des fichiers de thème à part;
- Sa stabilité, j’ai toujours pas eu de bugs;
- Sa réactivité, l’auteur d’Awesome est vraiment quelqu’un de très sympas et compétent, ouvert à toutes propositions; et avance vraiment bien le développement d’awesome.
Les moins :
- Lua, c’est tout pourri et c’est lent (je sais je suis pas très constructif mais j’ai pas le courage de disserter 10 ans sur Lua);
- On était sensé gagner en rapidité grâce à XCB, mais ce que moi j’observe au final, c’est qu’on perd le thème du curseur (oui XCB ne gère pas les curseurs X11) et que c’est plus lent qu’avant (merci Lua);
- Y’a de la documentation, mais faut chercher 10 ans, c’est mal organisé et éparpillé de partout; si bien qu’on a parfois plus vite fais d’aller directement regarder dans le code source d’Awesome;
- La disparition d’awesome-menu, il était pourtant bien pratique, à la place on a un prompt intégré à Awesome 3.2 avec une complétion bash, mais je ne trouve pas cela satisfaisant, j’ai une console pour ça. Du coup j’ai installé dmenu.
Voilà les impressions qu’Awesome 3.2 m’ont laissé. Mais je pense clairement y resté tout cela me semble très prometteur.
Note: pour la question de la rapidité, j’ai constaté des lenteurs notament sur les changements de bureaux mais aussi, et principalement, sur mes scripts de mise à jour de ma bar de status. Un script qui en bash s’exécutait sans aucun problème à 183Mhz toutes les deux secondes sans augmenter la fréquence du processeur fait sauter mon processeur toutes les deux secondes à 1,4Ghz… Mais Awesome n’y est pour rien c’est de la faute à Lua (si ce n’est d’avoir choisi Lua …). Accessoirement j’ai résolu le problème en mettant toutes mes commandes bash dans un seul popen et en récupérant les résultats ligne par ligne, comme ça Lua n’a pas besoin de lancer 36 shells.
6 réponses à 'Awesome 3.2, et c’est de nouveau «awesome»!'
Ecrire une réponse
You must be logged in to post a comment.
le 31/03/09 à 10:59
Vas-y, dissertes sur Lua. Argumentes, parce que jusqu’à là c’est du FUD. La performance et l’utilité de Lua n’est plus à démontré vu tous les jeux qui l’utilisent.
le 31/03/09 à 13:28
Hum… Windows est utilisé par combien de personnes déjà ? Quelque chose comme 99% du marché ? Pourtant j’attend toujours qu’on me démontre ses performances et ses utilités…
Lua c’est pareil. Accessoirement un développeur de Crysis a expliqué qu’au début ils utilisaient Lua de partout, puis qu’ils ont eu «quelques» problèmes de performances et que maintenant ils virent Lua de partout où ils le peuvent.
Et puis tu peux aussi me dire que bon nombre de ces jeux vidéos utilisent C++, moi je te répondrais que C++ est moisi et que c’est une faute énorme que de l’utiliser.
Bref pour en revenir à Lua, je trouve la syntaxe horrible (le coup du table.insert c’est quand même super fort) et c’est lent… mes arguments je les ai déjà donnés, avant j’utilisait awesome 3 à 183Mhz plus maintenant c’est tout.
Rajoutons le coup du «Oué oué nous on utilise que des doubles les integers ça sert à rien tout le monde le sait» rien que ça, ça mérite le fouet.
le 31/03/09 à 18:51
Mea Culpa, je n’étais réellement pas au courant. Pourtant de partout je vois qu’au contraire, c’est un des langages “interprété”(enfin de script c’est plus correct) le plus rapide ?
Et que proposerais-tu à la place pour retrouver la même puissance de configuration ?
Écoute. Je crois que ce problême vient surtout du fait que l’on croit que dès qu’on a un langage de script, faut tout faire avec. Est-ce bien la solution de programmer le menu déroulant du clic gauche en Lua ? Non. On fait une routine de C ou ce que tu veux, et on l’appelle à chaque clic en Lua. Ca doit servir à lier chaque composant ensemble … pas se substituer à toute les actions que tu puisses effectuer avec ton WM. Voilà ma vision des choses, après je suis loin d’être une référence.
La comparaison /windows était un peu facile je trouve. Je n’ai pas dit que c’était génial parce que tout le monde l’utilisait, mais que si on l’utilisait dans des endroits où les performances ne sont pas à négliger ce n’était pas pour rien …
le 31/03/09 à 18:52
Par contre la citation entre guillement je ne la comprend pas. Qui l’a dite ? Elle est sur Lua.org ?
le 31/03/09 à 20:14
Entre guillemet je faisais référence à ce passage du livre «Programming in Lua»:
«The number type represents real (double-precision floating-point) numbers. Lua has no integer type, as it does not need it. There is a widespread misconception about floating-point arithmetic errors and some people fear that even a simple increment can go weird with floating-point numbers. The fact is that, when you use a double to represent an integer, there is no rounding error at all (unless the number is greater than 100,000,000,000,000). Specifically, a Lua number can represent any long integer without rounding problems. Moreover, most modern CPUs do floating-point arithmetic as fast as (or even faster than) integer arithmetic.»
Sinon pour ce que tu dis sur l’utilisation des langages de scripts oui je suis d’accord avec toi. Personnellement, j’aurai préféré quelque chose comme perl ou guile (scheme). Mais je reconnais que Lua a des tas de côté pratique et que configurer awesome 3.2 est bien plus sympatoche que configurer awesome 2.x.
Et pour l’exemple de Windows, forcément c’est le plus facile, mais ça marche avec des tas d’autres choses. Je t’ai donné l’exemple de C++, mais tu peux aussi trouver des tas de serveur «temps réel» (ils n’en n’ont que le nom) programmés en Java. Et la liste de ce genre d’abérations est très très longue. Non franchement l’utilisation d’un outil/langage par de nombreux projets n’est pas un critère de sa qualité pour moi.
le 01/04/09 à 18:02
Je ne peux rien répondre, et je comprend tes arguments. Scheme serait plus lent encore non ?
ça ne doit pas être insoluble. Mais n’empêche que c’est un choix technique de merde. Pour le reste, nos désaccords sont uniquement une question de goût.
Perl, Scheme et tout les autres sont de grosses machines à gaz. Ca n’a rien à faire dans un fichier de configuration à la con.
Ce que je retiens moi, c’est la simplicité du langage ce que tu trouves abbêrant je le trouve très pratique, il est juste ce qu’on demande on ne fait pas le café avec. CPU moderne hein ? Stupide ce truc. C’est un gros point noir à revoir. Je le ferais un jour