Matthieu Moy a écrit 3249 commentaires

J'avais aussi mentionné asciidoc et rst2html. markdown, que tu proposes comme nom, existe aussi et fait la même chose.

Pourquoi en faire encore un autre ?

> Ta télé que je sache elle t'observe pas

Ta télé, elle sait quand tu es devant et ce que tu regardes. Elle sait que tu as commencé à regarder Ko-Lanta mais que tu as zappé sur une autre chaine 3 secondes après le début de la pause pub, ... et si c'est de la télé via ADSL ({alice,live,free,...}box), elle le dit illico à ton fournisseur d'accès (elle a pas vraiment le choix, il faut bien qu'elle récupère le flux vidéo à afficher).

> un langage qui force par exemple à commenter les classes

Mouais ...

/** Classe toto */
class toto {
public:
/** Renvoie la valeur du membre titi, un entier */
int get_titi();
private:
int titi;
};

Tu peux forcer les gens à écrire des commentaires, mais pas à écrire des commentaires pertinents. Et quand le code est assez simple pour se passer de commentaires, il vaut mieux effectivement ne pas en avoir.

Chez moi, le screenshot dit « Error establishing a database connection ». Bah si c'est ça l'avenir de firefox, ça promet ;-).

Ce qu'il faut voir aussi, c'est qu'au départ, la priorité était au support du C, et tant qu'il n'était pas assez bon, y'avait pas tellement de raison de bosser sur le C++.

Aujourd'hui, le support du C est raisonnable, donc c'est assez logique que la main d'oeuvre arrive sur le C++.

http://trollometre.com/measure?url=http%3A%2F%2Flinuxfr.org%(...)

Que 187 points.

> man git foo

Regardes bien ce que ça fait et tu seras moins entousiaste : ça fait en gros

man git; man foo

tout simplement. C'est le fonctionnement de man qui est comme ça, et on peut difficilement faire autrement.

Pff, moi qui avais fait un effort pour pas écrire deprecated ;-)

> HEAD~n : le nième parent de HEAD

=> pas vraiment. C'est l'ancètre de N-ième génération (i.e. le grand-grand-grand-....-père).

Le nième parent, c'est plutôt HEAD^n (vu qu'un commit peut avoir plusieurs parents en cas de merge).

La syntaxe git-foo est la forme dépréciée de git foo (sans tiret). Les commandes avec tirets ne sont plus installées dans le $PATH depuis la 1.6.0, autant ne pas les mentionner du tout dans un tuto.

Oui et non. Essayes de versionner une partition de 100Go avec Git, la moindre opération va prendre plusieurs minutes. Et côté utilisation du disque, avec Git, tu auras au moins une copie du fichier sur le disque, et une autre (compressée) dans .git/.

Les snapshots, c'est un truc à peu près instantané quelle que soit la taille de la partition, et qui ne stocke pas en double les trucs qui n'ont pas à l'être.

Par ailleurs, une fonctionnalité importante d'un gestionnaire de backup est de pouvoir oublier certains snapshots (typiquement, faire un snapshot par minute conservé quelques minutes, puis un par heure conservé sur la journée, puis un par jour, ...). Avec Git, au contraire, une fonctionnalité essentielle est qu'on ne peut pas éditer l'historique sans tout casser.

Bref, un système de backup à base de snapshot et un gestionnaire de versions, c'est pas fait pour la même chose, et ça ne répond pas aux mêmes besoins.

mél : abreviation de « messagerie électronique ». À la limite, celui-là, je le trouve plutôt bien vu, y'a au moins un semblant de pretexte de traduction.

> ... est ce que c'est du hardware, ou du logiciel proprio

C'est facile :
si le firmware est dans une mémoire flash dans le périphérique, c'est du HW => glop.
Si le même firmware est envoyé au périphérique par ton OS, c'est du SW => pas glop, vilain, privateur, blob, nazi, ubuntu, etc.

(et si tu penses à écrire un langage avec l'indépendance de l'architecture en tête depuis le source, dans l'optique de pouvoir distribuer les applis sous forme de byte-code, j'ai un scoop : ça s'appelle Java ...)

> il me semble qu'ils assurent que leur bytecode est indépendant de l'architecture.

Non, ce n'est pas le cas. Enfin, le bitcode est plus ou moins indépendant de l'architecture, mais c'est la chaine de compilation en partant du C qui ne l'est pas. Pour prendre un exemple caricatural, comment représenterait-t-on

printf("%d\n", sizeof(int));

en bitcode indépendant de l'architecture ?

Pour les détails, cf. par exemple http://markmail.org/message/chucijjh6ki4jz5c

> > je conçois mal comment un code diffusé à des milliers d'étudiants ne pointe pas le bout de son nez.

> Ca s'appelle la menace de se prendre un gros proces en pleine figure.

Et d'ailleurs, c'est pas comme si y'avait pas eu des fuites (enfin, au moins une à ma connaissance).

Oui, il sait faire des blagues, mais je t'assure que quand il s'énerve parce que quelqu'un a prononcé un mot qu'il n'aime pas (j'ai testé « Red Hat », ça marche assez bien), il vaut mieux pas essayer de contre-argumenter. Il traite les gens de fascistes pour un oui ou pour un non (vécu : le RMS qui s'égosille « these guys are fascists !! this is censorship ! » parce que le réseau était tombé en panne et qu'il pouvait plus lire ses mails ...). Bref, dire qu'il est pas sectaire mais que c'est juste pour de rire, c'est sympa, m'enfin ...

> j'ai plutôt pensé qu'il ne se prenait pas tant que ça au sérieux, jouait la caricature à fond et s'amusait du côté sectaire.

Pour avoir passé un peu plus d'une journée avec lui, je peux t'assurer qu'il est quand même très premier degré comme bonhomme ...

> Merci pour ton résumé des infos.

Je plussoie, et surenchérie ! Super boulot pour cette dépêche, ça m'a permis de rattraper mon retard au retour de vacances ;-).

... 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é.