Matthieu Moy a écrit 3255 commentaires

... Oui, je vais te dire ça.

Un répertoire qui prends de l'espace disque sur une partition au fur et à mesure qu'il se remplit, ça existe déjà, il suffit de mettre ledit répertoire sur une partition, c'est tout.

Si tu veux que /tmp/ prenne l'espace disque sur /dev/hda1, bah, faut mettre /tmp sur la partition /dev/hda1.

Et avec ESD qui tourne, tu arrives à avoir du son dans les applies KDE ?

Moi, j'ai jamais compris les détails de ces trucs là, mais sans pulseaudio, j'ai régulièrement des applies qui n'arrivent pas à donner de son, et en général, la solution est de tuer artsd et/ou esd qui monopolise la carte son, et de relancer l'appli problematique.

Pulseaudio n'est sans doute pas parfait, mais dans l'idée, avoir _un_ serveur de son au lieu de laisser chaque ensemble d'applis développer le sien incompatible avec les autres, c'est quand même une drolement bonne idée.

Je connais pas trop pulseaudio, m'enfin à comparer à ses ancêtres que sont artsd et esd et que tu omet soigneusement de citer dans ton journal, ça m'étonnerais que ça soit vraiment pire.

Je ne suis pas sûr de comprendre l'article sur Flash. Si je comprends bien, c'est un framework de lecteurs vidéos par dessus flash qui est libéré, mais pas l'élément central, qui est flashplayer lui-même. Du coup, « Les technologies Flash désormais disponibles en Open Source » me semble un peu enthousiaste, ça serait plutôt « Des technologies flash ... ».

Un intérêt, c'est de pouvoir faire tourner des applies x86 à l'intérieur d'une applet Java. Maintenant, c'est clair que les perfs seront forcément pas terribles ... Leurs démos sont rigolotes, mais je n'en ai pas trouvé qui soient vraiment « utiles ».

Si c'est la phase de link qui est lente, ce n'est pas tellement un problème de gcc. Il faut voir que ce qu'on appelle GCC est en fait un compilateur (le binaire est cc1) et un « driver » (le fameux binaire gcc) qui appelle dans l'ordre le compilateur, l'assembleur, le linker. L'assembleur et le linker sont des binaires qui ne font pas partie de GCC.

Sous Linux, a priori, c'est GNU ld qui sera appelé. Mais est-ce le cas sous Windows (gcc --verbose te le dira) ? Je ne serai pas surpris que ce soit simplement un autre linker, plus rapide, qui soit applé.

> la question qu'on te pose lorsque tu crée un journal quoi...

Ça marche seulement quand tu poste sur IPOT, donc il est excusable, quand même.

Ah, le bon vieux temps de StarOffice !

> \usepackage[francais]{babel}

Mais du coup les espaces insécables devant les !, :, ; sont inutiles aussi.

> Il y a juste certains caractères comme les guillemets « », les caractères œ æ, etc qui sont
> remplacés par leur équivalent en LaTeX.

Pourquoi donc ? Si on a le bon \usepackage[...]{inputenc}, c'est aussi pratique d'avoir les vrais caractères dans le texte source, non ?

Quelle que soit la couleur, le problème, c'est que la news reste longtemps là où elle est, donc on s'y habitue, et on ne la regarde plus.

Faut voir aussi que le meilleur compilateur du monde ne rendra pas un disque dur ou une carte réseau plus rapide. Le compilateur, ça peut accélérer les calculs, mais pas les I/Os, qui représentent quand même une partie pas négligeable du temps d'exécution d'un logiciel classique !

Le débat Libre/OpenSource n'a rien à voir avec GPL/BSD. La GPL comme la BSD est à la fois libre et opensource.

Tu confonds avec libre/copyleft, et éventuellement GNU/pas GNU.

$ zip
[...]
-e encrypt
$ ls -l =zip =unzip
-rwxr-xr-x 2 root root 121372 2008-07-26 17:37 /usr/bin/unzip*
-rwxr-xr-x 1 root root 67328 2006-07-06 23:27 /usr/bin/zip*


Je trouve rien pour extraire du zip avec l'utilitaire zip lui-même, et avec un unzip deux fois plus gros que zip, c'est peu probable que ça existe :-(. (yapuka compiler)

Shift-insert, c'est pas juste un reste du DOS. Dans la plupart des applis X11, ça colle le texte selectionné (comme clic du milieu), alors que C-v colle ce qui a été collé avec C-c quand l'appli le supporte. Par exemple, Shift-insert est à ma connaissance la seule solution pour coller du texte dans un xterm sans la souris.

Sinon, je confirme, la touche Ctrl de droite, quand on tape avec ses deux mains, elle sert pour toutes les combinaisons avec une lettre tappée avec la main gauche. Taper C-a d'une main alors qu'on avait les deux mains sur le clavier, c'est inefficace au possible.

> Pour moi un éditeur de texte te permet de manipuler seulement du texte plat.

Tiens, ça tombe bien, c'est pile ce que fait latex-preview.

Bon, documentes-toi sur ce dont tu parles, ou arrête le thread, ça ne mène nulle part.

>>un éditeur de texte qui sait afficher des images.
> Ce n'est donc plus un éditeur de texte.

Tu as probablement une définition d'éditeur de texte différente de la mienne, mais pour moi, un éditeur de texte, c'est un truc qui sert à éditer des fichiers textes. Ça n'a rien de contradictoire avec le fait d'afficher des images (typiquement, latex-preview).

Ça s'appelle comment, dans ton monde, Emacs + latex-preview ?

Deux xterm différents avec le même Emacs, c'est très pratique quand EDITOR=emacsclient, depuis n'importe quel xterm, une appli qui lance un éditeur va se connecter à ton Emacs existant sans le perturber (là, il y a aussi une faiblesse d'Emacs, c'est qu'un Emacs configuré à mort met deux plombes à démarrer, donc en dehors du fait de partager la liste des buffers et autres, emacsclient permet surtout de démarrer quasi-instantanément. On aurait été sous vi ça aurait été moins génant de démarer une nouvelle instance).

Un Emacs graphique et un autre en mode texte, j'utilise ça tous les jours : je préfère un Emacs graphique (plus de couleurs différentes disponibles que dans un xterm, donc plus joli à mon goût, des fois copier-coller à la souris, et les menus pour les modes que je ne connais pas bien pour chercher les commandes), mais quand je suis chez moi et que je me connecte au labo, je préfère le mode texte (plus réactif via la liaison ADSL), mais j'apprécie de me connecter au même Emacs quand même.

> Dsl mais bazaar n'est pas bitkeeper contrairement à ce qu'affirme Matt

Ouais, et après ça, c'est les autres qui FUDent ...

Le fait que Canonical se laisse la possibilité de faire du propriétaire avec bzr, ce n'est pas du FUD, c'est dit explicitement dans la page en question :

6. Canonical will make the Assigned Contributions available under a "Free
Software Licence", according to the definition of that term published by the
Free Software Foundation. Such a licence will, at minimum, permit
people receiving the software, without payment of a royalty to Canonical, to
use, modify and redistribute under the same licence. Canonical may also make
the Assigned Contributions available under other license terms.

Si c'était juste pour les changements de licences libres, la première partie suffisait.

Maintenant, non, Canonical n'est pas la seule boite à faire ça. L'existence de StarOffice n'empêche pas OpenOffice d'exister et d'être libre, au contraire. Ce qui me dérange avec Canonical, c'est le discours ambigüe de Mark Shuttleworth sur le logiciel libre. Dans le discours, il a monté Canonical pour des raisons ethiques, il veut du bien à Debian, contribuer en upstream ... et dans les faits, il héberge sa boite dans un paradis fiscal, freine plutôt le développement de Debian qu'autre chose, beaucoup de gens se plaignent du peu de contributions en upstream. Quand c'est une boite qui annonce clairement qu'ils sont là pour faire de la thune, à la limite, les choses sont claires, mais j'ai du mal à être à l'aise avec une boite qui utilise explicitement les arguments ethiques pour attirer du monde (cf. l'appel de Mark Shuttleworth aux développeurs de SuSE « Abandonnez les maichants, venez plutôt chez nous, c'est nous les gentils » par exemple), avec une position aussi ambigüe.

> Et dans screen tu n'as pas nécessairement le même affichage sur les différents
> terminaux, c'est le cas seulement si tu affiches la même fenêtre de la même session.

Je connais mal screen, mais il y a _vraiment_ un moyen de faire afficher des trucs différents dans des terminaux différents par _la même appli_ sans support de l'application en question ?

Si c'est le cas, je veux bien voir les commandes qui le font.

D'une part, tu auras deux fois le même affichage dans les deux instances de screen, alors qu'un emacsclient te permet de faire des choses différentes dans des terminaux différents.

Et surtout, oui, si ta notion de « sous X11 », c'est « dans un xterm qui tourne sous X11 », effectivement, tu peux tout faire sous X11. M'enfin, en général, quand on te parle d'application X11, c'est pas limité aux emulateurs de terminaux ...

Tu fais comment avec screen pour avoir une même appli qui s'affiche sur plusieurs terminaux tout en ayant une fenêtre X11 ouverte ?

Pour Git j'ai parfois le sentiment que c'est le choix des développeurs ou des admins les plus influents qui l'emporte.

Regarde par exemple le sondage qu'a fait GNOME avant de migrer :

http://blogs.gnome.org/newren/2009/01/03/gnome-dvcs-survey-r(...)

Git est populaire, c'est un fait. Tu peux aimer ou pas, mais essayer de faire croire que c'est juste des vilains qui forcent les gentils à utiliser Git alors que Mercurial est mieux, c'est du FUD de bas de gamme.

Le site de Git aussi était moche avant. http://git-scm.com/ n'exsite que depuis peu. Et hop, le même est en préparation pour Mercurial : http://hg-scm.org/