Posté par nud .
En réponse au journal GNOME 3.
Évalué à 2.
Moui, le "ramasse-miette" de python c'est quand même surtout du refcounting avec les objets free-és directement quand ob_refcnt arrive à 0. Le "gc", qui n'est pas là depuis très longtemps, est surtout là pour dégotter de temps à autre les références cycliques, mais je dirais que le gros de la ram gaspillée par python et awn est surtout dû au fait que c'est un langage interprété et dynamique. Tu aurais moin rouspété si AWN avait été codé en C ou C++ avec un GC type boehm que tu n'aurais même pas remarqué.
AMHA il faut plutôt distinguer langages interprétés (bytecode inclus) vs natifs et dynamiques vs statiques que vraiment gc vs pas de gc...
Je dois dire que globalement j'apprécie très fortement le nouveau gnome shell, d'autant plus que depuis lundi le driver nouveau disponible dans debian expérimental assomme les loutres avec des poutres en chêne massif. Ça a bien évolué depuis l'apparition du bug clutter avec le driver nvidia qui m'avait empêché de continuer à orienter le shell dans la bonne direction à coup de patches ciblés ;-).
Le seul truc qui est embêtant, c'est qu'il est orienté applications. Ce qui en soit n'est pas un mal, il faut juste préciser ce que l'on appelle application. Et pour le shell, une application c'est par exemple "gnome-terminal". Donc le truc qui m'embête, c'est que gnome-shell ne fait pas la différence entre mon terminal 'ssh + tmux + irssi' et mes autres terminaux...
Il ne faut pas non plus prendre gnome dans son ensemble pour toutes les conneries que l'on voit. Gnome c'est un ensemble de mainteneurs auxquels on peut suggérer des choses mais qui restent libres de toute décision.
Le tout est d'y penser. Je ne crois pas que quiconque ait envie de perdre les commentaires non lus donc autant de toute façon les supporter correctement non?
Pour moi le problème le plus embêtant avec les commentaires est le suivant: quand on ajoute un commentaire on quitte la page et on perd le compte des nouveaux commentaires.
C'est problématique car si il y a 10 nouveaux commentaires sur 1236 au total, et que je réponds au 2e de ces nouveaux commentaires, je vais avoir du mal à retrouver les autres...
Cependant, pour peu que ce tracas soit corrigé, il n'est pas nécessaire pour moi de ne pas quitter la page pour ajouter un commentaire, on pourrait faire un truc à la google reader qui marque un commentaire comme lu à partir du moment où on a scrollé jusqu'à lui, ou bien mémoriser l'état des nouveaux commentaires et le restaurer quand on revient sur la page après avoir envoyé le commentaire...
"absence de bouton d'arrêt", je bondis. C'est complètement hors de propos
Oui, personne n'a dit non plus que toutes les décisions étaient bonnes et avaient un sens.
Moi tu me proposes une voiture sans jauge, je ne te l'achète pas.
Le tout est de savoir pourquoi tu utilises la jauge. Souvent c'est pour estimer "au pif", d'un coup d'oeil, la distance que la voiture peut encore parcourir avant d'aller à la pompe. Si on avait une info fiable du nombre de km restants en lieu et place de la jauge j'imagine que tu ne t'en porterais pas plus mal...
3- raccourci clavier qui réduit toutes les fenêtres.
Essaie la touche super.
maintenir la prise ( maintenir le clic enfoncé ) glisser l'appli dans un autre espace ( bouger la souris jusqu'à provoquer le contexte de l'autre espace )( si ça marche, le glisser déposé, c'est pas pour les manchots ).
Cliquer sur l'appli en question dans les favoris à gauche fonctionne aussi et affiche la fenêtre dans le workspace courant.
Pourquoi est-ce que donner son avis sur une proposition, aux yeux de certains, placent directement l'utilisateur insatisfait dans la catégorie des gens " figés " ?
Je pense surtout qu'il faut laisser aux gens l'occasion de tester gnome shell un certain temps et d'émettre des opinions. Certains choix se révèleront mauvais, d'autres seront adoptés. Certains aimeront, d'autre pas. C'est tout.
Tu peux demander à ce que nautilus gère le bureau, mais par défaut, ça n'a pas de sens puisque le bureau est centré sur l'application désormais.
Eh non, perdu, l'option a été supprimée de nautilus 3.0. Il est par contre possible d'utiliser d'autres gestionnaires de bureau comme par exemple xfdesktop.
JE ne suis pas certain que "goggles" soit suffisemment fiable pour assurer qu'il ne laissera jamais passer un contenu "interdit". Il trouve des trucs qui ressemblent, certes, mais il ne les trouve probablement pas tous. Il y a des faux négatifs tout comme il y a des faux positifs...
En plus, IANAL mais la copie partielle d'oeuvres soumises au droit d'auteur est autorisée dans certains cas précis que google ou tout autre serait bien en peine de déterminer automatiquement. Prenons par exemple la parodie. Est-ce le rôle de Google de censurer dans ce cas ?
Mais cela n'est pas bien grave, de toute façon nous avons tous un pare-feu OpenOffice.
IANAL, mais le concept de vie privée et vie publique est aussi défini par la loi.
Par exemple en Belgique et dans le cadre du droit à l'image, tu ne peux pas publier de photos de quelqu'un sans son accord sauf dans certains cas précis, par exemple:
la personne participe à une manifestation publique (une soirée entre potes ne compte pas, on parle plutôt d'une manifestation etc)
la personne participe à une soirée organisée, etc. où les participants sont explicitement avertis de la possibilité de prendre et publier des photos (auquel cas l'accord est implicite)
la personne n'est pas le sujet principal de la photo (par exemple le photographe voulait photographier un bâtiment public mais la personne passant devant à ce moment)
Il n'existe pas de concept de vie semi-publique, c'est juste que les gens ne savent pas / ignorent sciement ce droit, et il n'est guère pratique d'aller au tribunal face à tous ses "amis de Facebook"...
Note que dans le genre, Python/ruby/whatever compile vachement vite aussi, tellement qu'ils se cassent même pas le cul à compiler les trucs à l'avance ;-)
Plus sérieusement, vu qu'il y a une interprétation de bytecode (niveau intermédiaire) qui est faite au runtime, il y a moins de choses à traduire et optimiser au build time, donc ça va forcément plus vite. Il n'y a rien de magique là-derrière si tu veux mon avis.
L'openspace c'est aussi une façon de gagner des sous aux dépends du développeur en ne lui donnant que le minimum d'espace possible (les murs et les couloirs, c'est du gaspillage de place, c'est bien connu).
La problématique open-space vs bureaux indidivuels est abordée dans "the Mythical Man Month". Et si j'avais le choix, j'aurais un bureau individuel.
Même si ce "truc" marche, il faut quand même le maintenir, le mettre à jour pour supporter les nouvelles APIs, tester voir s'il fonctionne toujours après les modifications apportées à d'autres endroits du programme, etc.
Sinon si on veut garder toutes les API disponibles pendant toute la vie du produit, on arrive à un truc comme OpenOffice qui a vraiment les fesses lourdes (c'est pas pour rien que les petits gars de LibreOffice ont commencé par un nettoyage du code)
Avec gstreamer tu dois pouvoir faire ça pas trop difficilement en python.
tu as filesrc / filesink qui permettent de lire et écriredes fichiers
tu as 150 décodeurs et encodeurs différents (vorbisenc, oggmux et all)
tu as le plugin gnlcomposition (de gnonlin) qui permet entre autres de faire des découpes
Y'a pas mal de documentation sur comment utiliser pygst (les bindings python), et y'a du code pour s'inspirer dans jokosher ou pitivi. Y'a aussi man gst-launch qui est bien fait sur comment créer sa pipeline.
Le point négatif évidemment c'est que tu dépends d'une lib en C, mais je doute que tu trouves un équivalent en pur python qui soit un tant soit peu efficace.
Tu peux par ailleurs aussi utiliser gst-launch pour tester ou faire cela en ligne de commande. Mais si tu veux de la ligne de commande brute, tu peux aussi regarder du côté de sox.
Je seconde. La taille des polices explose vraiment les yeux actuellement. Surtout que pas mal de gens scotchés plus de 8h par jour à un écran ont des problèmes de vue (moi y compris) donc autant éviter de les empirer... Une police un peu plus grande ne serait pas de refus.
Ben en fait je pense que markdown est relativement bien adapté aux gens qui veulent écrire, dans vim ou emacs, un document à mouliner ensuite pour créer du html. Avec ces éditeurs, on a de l'auto-indent, on peut afficher les "trailing whitespace", et on peut mettre un retour à la ligne après 78 caractères quand on n'aime pas le word-wrap automatique. Et au final ça donne un document dont le source est lisible et compréhensible par tout un chacun.
Ici on n'est (généralement) pas dans vi, donc on n'a pas l'auto-indentation, on n'a pas de coloration, et on a toujours le word-wrap, donc à quoi bon mettre des retours à la ligne partout ? Du coup certaines constructions markdowniennes deviennent un peu compliquées à utiliser correctement.
Les cas et contextes d'utilisation sont très différents entre un moteur de blog statique et une boite de commentaire sur linuxfr...
Je pense qu'il faut quand même différencier le cas d'un document que tu édites avec ton éditeur de texte et celui d'une textarea sur un site comme linuxfr...
Via ton ~/.vimrc tu peux rajouter des choses de ce style:
autocmd BufRead *.tpl set ft=html
L'avantage par rapport à la modeline du commentaire précédent, c'est que tu n'es pas dépendant du mainteneur pour inclure la modeline dans le repo, et tu n'as pas besoin de le faire pour chaque fichier.
[^] # Re: Conso mémoire
Posté par nud . En réponse au journal GNOME 3. Évalué à 2.
Moui, le "ramasse-miette" de python c'est quand même surtout du refcounting avec les objets free-és directement quand ob_refcnt arrive à 0. Le "gc", qui n'est pas là depuis très longtemps, est surtout là pour dégotter de temps à autre les références cycliques, mais je dirais que le gros de la ram gaspillée par python et awn est surtout dû au fait que c'est un langage interprété et dynamique. Tu aurais moin rouspété si AWN avait été codé en C ou C++ avec un GC type boehm que tu n'aurais même pas remarqué.
AMHA il faut plutôt distinguer langages interprétés (bytecode inclus) vs natifs et dynamiques vs statiques que vraiment gc vs pas de gc...
# "Applications"
Posté par nud . En réponse à la dépêche GNOME 3.0 : le grand saut !. Évalué à 3.
Je dois dire que globalement j'apprécie très fortement le nouveau gnome shell, d'autant plus que depuis lundi le driver nouveau disponible dans debian expérimental assomme les loutres avec des poutres en chêne massif. Ça a bien évolué depuis l'apparition du bug clutter avec le driver nvidia qui m'avait empêché de continuer à orienter le shell dans la bonne direction à coup de patches ciblés ;-).
Le seul truc qui est embêtant, c'est qu'il est orienté applications. Ce qui en soit n'est pas un mal, il faut juste préciser ce que l'on appelle application. Et pour le shell, une application c'est par exemple "gnome-terminal". Donc le truc qui m'embête, c'est que gnome-shell ne fait pas la différence entre mon terminal 'ssh + tmux + irssi' et mes autres terminaux...
Mais bon, ça va venir, j'espère !
[^] # Re: GNOME 3.0, ou comment se tirer une balle dans le pied
Posté par nud . En réponse à la dépêche GNOME 3.0 : le grand saut !. Évalué à 2.
Il ne faut pas non plus prendre gnome dans son ensemble pour toutes les conneries que l'on voit. Gnome c'est un ensemble de mainteneurs auxquels on peut suggérer des choses mais qui restent libres de toute décision.
Ici le mainteneur de gnome-screensaver a foiré.
[^] # Re: GStreamer
Posté par nud . En réponse au message librairie python pour découper du flac. Évalué à 2.
Euh, gstreamer ne nécessite pas de X11, sauf pour certains modules optionnels genre affichage sur l'écran.
[^] # Re: Retrouver les nouveaux commentaires
Posté par nud . En réponse à l’entrée du suivi Ergonomie lors de l'ajout d'un commentaire. Évalué à 1 (+0/-0).
Le tout est d'y penser. Je ne crois pas que quiconque ait envie de perdre les commentaires non lus donc autant de toute façon les supporter correctement non?
[^] # Re: GStreamer
Posté par nud . En réponse au message librairie python pour découper du flac. Évalué à 1.
C'est du python ça ? ;-)
# Retrouver les nouveaux commentaires
Posté par nud . En réponse à l’entrée du suivi Ergonomie lors de l'ajout d'un commentaire. Évalué à 1 (+0/-0).
Pour moi le problème le plus embêtant avec les commentaires est le suivant: quand on ajoute un commentaire on quitte la page et on perd le compte des nouveaux commentaires.
C'est problématique car si il y a 10 nouveaux commentaires sur 1236 au total, et que je réponds au 2e de ces nouveaux commentaires, je vais avoir du mal à retrouver les autres...
Cependant, pour peu que ce tracas soit corrigé, il n'est pas nécessaire pour moi de ne pas quitter la page pour ajouter un commentaire, on pourrait faire un truc à la google reader qui marque un commentaire comme lu à partir du moment où on a scrollé jusqu'à lui, ou bien mémoriser l'état des nouveaux commentaires et le restaurer quand on revient sur la page après avoir envoyé le commentaire...
[^] # Re: Xfce…
Posté par nud . En réponse au journal Test de gnome 3. Évalué à 2.
Oui, personne n'a dit non plus que toutes les décisions étaient bonnes et avaient un sens.
Le tout est de savoir pourquoi tu utilises la jauge. Souvent c'est pour estimer "au pif", d'un coup d'oeil, la distance que la voiture peut encore parcourir avant d'aller à la pompe. Si on avait une info fiable du nombre de km restants en lieu et place de la jauge j'imagine que tu ne t'en porterais pas plus mal...
Essaie la touche super.
Cliquer sur l'appli en question dans les favoris à gauche fonctionne aussi et affiche la fenêtre dans le workspace courant.
Je pense surtout qu'il faut laisser aux gens l'occasion de tester gnome shell un certain temps et d'émettre des opinions. Certains choix se révèleront mauvais, d'autres seront adoptés. Certains aimeront, d'autre pas. C'est tout.
[^] # Re: Précisions
Posté par nud . En réponse au journal Test de gnome 3. Évalué à 2.
Eh non, perdu, l'option a été supprimée de nautilus 3.0. Il est par contre possible d'utiliser d'autres gestionnaires de bureau comme par exemple xfdesktop.
[^] # Re: Goggles
Posté par nud . En réponse au journal Des juges croient à la magie. Évalué à 6.
JE ne suis pas certain que "goggles" soit suffisemment fiable pour assurer qu'il ne laissera jamais passer un contenu "interdit". Il trouve des trucs qui ressemblent, certes, mais il ne les trouve probablement pas tous. Il y a des faux négatifs tout comme il y a des faux positifs...
En plus, IANAL mais la copie partielle d'oeuvres soumises au droit d'auteur est autorisée dans certains cas précis que google ou tout autre serait bien en peine de déterminer automatiquement. Prenons par exemple la parodie. Est-ce le rôle de Google de censurer dans ce cas ?
Mais cela n'est pas bien grave, de toute façon nous avons tous un pare-feu OpenOffice.
[^] # Re: Après quelques jours d'utilisation...
Posté par nud . En réponse au journal Firefox 4 RC1. Évalué à 2.
C'est bizarre comme raccourci. Dans toutes les applications du monde (firefox compris), ctrl+s c'est pour sauvegarder...
# Mardi gras
Posté par nud . En réponse au journal 8 mars 2011 : International Women Day. Évalué à 9.
Demain c'est aussi le mardi gras. Est-ce une coïncidence ?
[^] # Re: La solution ultime (vie privée)++
Posté par nud . En réponse au journal Facebook abus et failles. Évalué à 1.
IANAL, mais le concept de vie privée et vie publique est aussi défini par la loi.
Par exemple en Belgique et dans le cadre du droit à l'image, tu ne peux pas publier de photos de quelqu'un sans son accord sauf dans certains cas précis, par exemple:
Il n'existe pas de concept de vie semi-publique, c'est juste que les gens ne savent pas / ignorent sciement ce droit, et il n'est guère pratique d'aller au tribunal face à tous ses "amis de Facebook"...
[^] # Re: C'est quoi ce troll?
Posté par nud . En réponse au journal Comment ça marche chez microsoft. Évalué à 2.
Note que dans le genre, Python/ruby/whatever compile vachement vite aussi, tellement qu'ils se cassent même pas le cul à compiler les trucs à l'avance ;-)
Plus sérieusement, vu qu'il y a une interprétation de bytecode (niveau intermédiaire) qui est faite au runtime, il y a moins de choses à traduire et optimiser au build time, donc ça va forcément plus vite. Il n'y a rien de magique là-derrière si tu veux mon avis.
[^] # Re: Mais comment?
Posté par nud . En réponse au journal Comment ça marche chez microsoft. Évalué à 6.
L'openspace c'est aussi une façon de gagner des sous aux dépends du développeur en ne lui donnant que le minimum d'espace possible (les murs et les couloirs, c'est du gaspillage de place, c'est bien connu).
La problématique open-space vs bureaux indidivuels est abordée dans "the Mythical Man Month". Et si j'avais le choix, j'aurais un bureau individuel.
[^] # Re: Mais comment?
Posté par nud . En réponse au journal Comment ça marche chez microsoft. Évalué à 4.
Même si ce "truc" marche, il faut quand même le maintenir, le mettre à jour pour supporter les nouvelles APIs, tester voir s'il fonctionne toujours après les modifications apportées à d'autres endroits du programme, etc.
Sinon si on veut garder toutes les API disponibles pendant toute la vie du produit, on arrive à un truc comme OpenOffice qui a vraiment les fesses lourdes (c'est pas pour rien que les petits gars de LibreOffice ont commencé par un nettoyage du code)
[^] # Re: GStreamer
Posté par nud . En réponse au message librairie python pour découper du flac. Évalué à 1.
And the obligatory example, for inspiration:
http://www.0d.be/2007/07/01/introducing-mrcut/
# GStreamer
Posté par nud . En réponse au message librairie python pour découper du flac. Évalué à 2.
Avec gstreamer tu dois pouvoir faire ça pas trop difficilement en python.
Y'a pas mal de documentation sur comment utiliser pygst (les bindings python), et y'a du code pour s'inspirer dans jokosher ou pitivi. Y'a aussi man gst-launch qui est bien fait sur comment créer sa pipeline.
Le point négatif évidemment c'est que tu dépends d'une lib en C, mais je doute que tu trouves un équivalent en pur python qui soit un tant soit peu efficace.
Tu peux par ailleurs aussi utiliser gst-launch pour tester ou faire cela en ligne de commande. Mais si tu veux de la ligne de commande brute, tu peux aussi regarder du côté de sox.
[^] # Re: Je suis français donc je râle
Posté par nud . En réponse à la dépêche Architecture logicielle de la nouvelle version de LinuxFr.org. Évalué à 1.
Ben en fait c'est plutôt la CSS qui devrait forcer des largeurs raisonables pour le texte...
[^] # Re: Retours à la ligne
Posté par nud . En réponse à la dépêche Architecture logicielle de la nouvelle version de LinuxFr.org. Évalué à 1.
C'est le genre de trucs que tu devrais mettre dans le ticket de suivi idoine pour "référence ultérieure" ;-)
[^] # Re: Retours à la ligne
Posté par nud . En réponse à la dépêche Architecture logicielle de la nouvelle version de LinuxFr.org. Évalué à 0.
Il pourrait vouloir écrire un dialogue.
[^] # Re: Commentaires
Posté par nud . En réponse à la dépêche Architecture logicielle de la nouvelle version de LinuxFr.org. Évalué à 0.
Je seconde. La taille des polices explose vraiment les yeux actuellement. Surtout que pas mal de gens scotchés plus de 8h par jour à un écran ont des problèmes de vue (moi y compris) donc autant éviter de les empirer... Une police un peu plus grande ne serait pas de refus.
[^] # Re: Q&A
Posté par nud . En réponse à la dépêche Architecture logicielle de la nouvelle version de LinuxFr.org. Évalué à 2.
Ben en fait je pense que markdown est relativement bien adapté aux gens qui veulent écrire, dans vim ou emacs, un document à mouliner ensuite pour créer du html. Avec ces éditeurs, on a de l'auto-indent, on peut afficher les "trailing whitespace", et on peut mettre un retour à la ligne après 78 caractères quand on n'aime pas le word-wrap automatique. Et au final ça donne un document dont le source est lisible et compréhensible par tout un chacun.
Ici on n'est (généralement) pas dans vi, donc on n'a pas l'auto-indentation, on n'a pas de coloration, et on a toujours le word-wrap, donc à quoi bon mettre des retours à la ligne partout ? Du coup certaines constructions markdowniennes deviennent un peu compliquées à utiliser correctement.
Les cas et contextes d'utilisation sont très différents entre un moteur de blog statique et une boite de commentaire sur linuxfr...
[^] # Re: Syntaxe
Posté par nud . En réponse à l’entrée du suivi Retour à la ligne ne fonctionne plus. Évalué à 1 (+0/-0).
Je pense qu'il faut quand même différencier le cas d'un document que tu édites avec ton éditeur de texte et celui d'une textarea sur un site comme linuxfr...
# Via vimrc
Posté par nud . En réponse au message Vim : mettre la syntaxe à utiliser dans le fichier. Évalué à 2.
Via ton ~/.vimrc tu peux rajouter des choses de ce style:
L'avantage par rapport à la modeline du commentaire précédent, c'est que tu n'es pas dépendant du mainteneur pour inclure la modeline dans le repo, et tu n'as pas besoin de le faire pour chaque fichier.