Matthieu Moy a écrit 3249 commentaires

Pas si grosse la coquille.

OGG vorbis est la compression sonore, mais il y a aussi OGG théora pour la compression vidéo. La version finale est prévue pour l'été 2003. Ahem, enfin, je veux dire, en même temps que E17 et The Hurd !

> je trouve dommage de dire "ca marche pas et puis bon on s'en fout, ils sont minoritaires de toutes façons".

Attends, il ne s'agit pas de rendre le site completement inaccessible aux non-voyants, ce qui serait purement scandaleux. Ca veut juste dire qu'ils ne pourraient pas voter pour les commentaires.

Vu l'utilité du système de vote, je pense qu'on peut vivre sans !

Ceci dit, l'ancien système (DaCode) était plutôt bien : On avait le popup, mais avec du javascript pour fermer le popup en question. Si t'as pas javascript, le popup reste ouvert, c'est tout.

Justement. La touche TAB circule par défaut entre les champs *et* les liens. Si ton formulaire contient pleins de liens (genre un lien sur lequel tu cliques pour avoir une explication sur le champ que tu es en train de remplir), il faut appuyer pleins de fois sur TAB pour arriver au suivant.

même pas besoin d'apostrophe. Tappes juste le texte, ça suffit !

> Je me fais un devoir de casser le mythe du linux qui marche mieux que le windows sur des config très light ...

En fait, la réalité, c'est que Linux tourne en général mieux que windows sur des configs light pour une utilisation geek-esque.

Si tu veux faire du vi+mutt+lynx en mode console, Linux a l'avantage.

Si tu veux faire un mini serveur web super stable qui traite 1 requête toute les dix minutes, Linux à l'avantage. (Vu qu'un Linux 2.0.beaucoup + un petit serveur web s'installent sur des machines qui feraient rigoler un windows NT)

Maintenant, pour une utilisation conviviale ou on clique sur des boutons et tout, c'est clair que je défie quiconque d'arriver au même niveau de convivalité qu'un Win98 sur une config matérielle équivalente.

Entre SO 5.2 et OOo 1.0, je crois quand même que OOo est *encore* plus lourd.

Par contre, c'est clair que l'idée d'installer un SO 5.2 pour plus de légerté par rapport à OOo 1.1, c'est un peu illusoire.

Rappelons qu'à l'époque, StarOffice, c'était une espèce de bureau tout intégré, qui tentait de remplacer le système d'exploitation. Dur de trouver plus lourd !

Les entreprises qui sont encore sous NT4 (30% des serveurs il n'y a pas si longtemps que ça il me semble !) ont gardé un système qui marchait et qu'elle ne voulaient pas changer.

Je ne pense pas qu'ils envisageraient une migration vers ReactOS plus qu'une migration vers Windows 2003 ...

Si tu n'as pas de serveur sur ta machine, le plus simple, c'est de jetter tout ce qui vient de l'extérieur, et d'autoriser tout ce qui sort.

Si tu es prêt à tapper 10 lignes de commandes, il y a un exemple qui fait ça dans la doc de iptables.

Ca parait compliqué à mettre en oeuvre, mais on le fait une fois au début, et on est protégé ad vitam eternam.

Oui, enfin, tu peux surtout avoir un démon en userland, genre lancé par ta session Gnome/Kde, qui se suspends en attente d'un nouveau paquet. (Il faut un module dans le kernel pour déclarer le sémaphore et se brancher sur les bons hooks dans la pile TCP/IP quand même, bien sur).

Quand tu recoit un paquet, le seul truc à faire est de réveiller le processus en attente, qui fait tout le traitement.

Maintenant, ça ne doit pas être bien difficile de rajouter une navigation au clavier ?

'j' ou 'n' => prochain commentaire
'k' ou 'p' => précédant commentaire

Regardes bien en bas de ton écran. La DLFP toolbar est ton amie ...

Au clavier, ça donne '>' puis ENTRÉE et hop, commentaire suivant (Sous moz)

> Je ne connais pas de Mutt-autoconfigurator capable de reprendre les mimes du systeme.

En même temps, le .mailcap et /etc/mailcap, c'est un truc plutôt standard sous Unix (remplacé petit à petit par les trucs de freedesktop). Donc, pour la plupart des applications, ton sysadmin ou ton gestionnaire de paquets a déjà fait le boulot. (Valable pour tous les mailers qui respectent cette convention)

> Je suppose que l'utilisation d'unison pourrait m'aider, non ?

A mon avis, c'est surtout suicidaire ;-)

Si tu fait de la fusion bidirectionnelle entre ton portable et ton bureau, tu as de forte chances de corrompre les fichiers d'index. Je ne sais plus comment marche maildir exactement, mais si tu supprimes un mail sur ton portable, que tu en rappatrie sur ton PC et que tu fusionne après, a mon avis ... :-(

Si mutt a un mode hors-ligne, le mieux, c'est un serveur IMAP sur ton bureau, tu y accède depuis ton portable, et activant l'option qui te permet de garder un cache local. Comme ça, tu as encore accès à tes mails quand tu part dans la jungle avec ton portable.

Sinon, une copie unidirectionnelle de ton PC vers ton portable me parait bien plus sure ...

Ca a des cotés pratiques, mais ça pose pas mal de problèmes.

Un des trucs les plus génant, c'est l'impossibilité de bookmarker ou de copier-coller une URL.

Ca arrive super souvent que quelqu'un copie l'url d'une page bien particulière, la colle dans un commentaire linuxfr, ou autre forum, et quand on clique dessus, paf!, on tombe sur la homepage du site :-(

ça casse en général le bouton "recharger" : Tu recharges le cadre le plus englobant, qui te ramène tous les cadres par défaut. Ca doit être contournable, mais par défaut, le bouton "recharger" te ramène sur la page d'accueil du site :-((

L'autre truc agaçant, c'est pour les liens extérieurs. Si tu ne prends pas la peine de mettre le code qui-va-bien pour les liens, le site pointé s'ouvre dans une frame. Si tous les sites étaient faits avec des frames, on pourrait jouer aux poupées russes au bout de quelques clics !

Ca ne veut pas forcément dire que les frames sont a banir, mais c'est à classer dans la catégorie des trucs à éviter et à réserver aux cas ou c'est vraiment nécessaire.

Avec du CSS, maintenant, on peut faire quelque chose de semblable : Un menu sur le coté, qui ne bouge pas quand tu fais défiler la page. Par contre, il faut un langage de script pour faire des inclusions coté serveur si tu ne veux pas recopier le menu dans toutes les pages.

> > RedHat modifie manifestement pas mal de trucs de base (compilo, glibc, emplacement d'en-têtes, structure des en-têtes, etc.)

> FUD. C'est vrai pour RHEL. Et encore...

Ben niveau trifouillage du compilateur, c'est quand même Red Hat qui a la palme d'or avec gcc 2.96, non ?

Si le lien sur l'exterme programing t'a plu, ceci est à lire de toute urgence :

http://www.linuxfr-france.org.invalid/article/these/cathedrale-bazar/cathedra(...)

Le même genre de théorie à été formalisé de pleins de façons différentes, mais ça revient toujours plus ou moins à la même chose :

Cathédrale <-> Bazar
Développement en V <-> Développement en spirale
Développement cascade <-> Développement incrémental
...

Il n'y en a pas un qui est meilleur que l'autre dans l'absolu. Souvent, le développement incrémental (on rajoute les fonctions une par une) est la solution de facilité. Mais au bout de quelques années à essayer de maintenir un projet qui avance pas à pas, surtout si on fait gaffe à chaque pas à garder la compatibilité avec l'existant, c'est parfois la cata. On se rends compte trop tard que le truc est mal pensé à la base et qu'il faut tout réécrire.

D'ailleurs, quand tu regardes l'évolution de pas mal de logiciels, souvent, les améliorations importantes correspondent à une réécriture complete d'une partie du programme. Regardes Mozilla, par exemple. Est-ce qu'ils auraient réussi à faire XUL en ajoutant des trucs "petit à petit" à Netscape 4 ? Non, heureusement qu'ils ont tout mis par terre pour faire Moz 1.0 !


Le fait que le logiciel soit libre ou pas a aussi son importance. Souvent, le logiciel propriétaire va adopter un cycle en cascade. On réfléchi bien, on fait plein de R&D, et un jour, on se met au boulot, on teste, et on sort une version 1.0.

Pour du logiciel libre, "realease early, release often" (Linus). Si tu veux des contributeurs, il faut une démo fonctionnelle le plus rapidement possible.


Après, il ne faut pas croire que ce que tu fais à l'école, c'est la même chose que ce que tu feras dans l'industrie. On essaye de te faire faire des trucs pédagogiques, de te montrer des trucs que tu n'aurais pas fait spontanément. Si on te laissait faire comme tu le sentais dès le début, ou est l'intérêt de l'école.

Et puis il faut voir aussi que les profs en école sont en général "vieux chercheurs", qui savent bien faire du LaTeX, mais pour ce qui est de coder, c'est plus que variable !

> tout récemment Arch

D'ailleurs, (c'est pas que je veuille faire du google bombing, mais bon ... si un peu quand même !)

L'interface Emacs pour Arch, et en particulier tla, s'appelle xtla, et tout est là:

http://wiki.gnuarch.org/moin.cgi/xtla(...)

Je passe mes nuits sur un projet qui sera intégré d'ici quelque temps à Debian.

Ca suffit, ou alors il faut que je recode l'installeur à partir de zero pour avoir le droit d'avoir un regard critique sur la distrib que j'utilise ?

Tiens, un géni de l'informatique qui remêt en cause une des fondations de l'informatique théorique. ;-)

> Le coup du f(f) avec le "f" interne sans paramètres....

Ben non, ça n'est pas faut. C'est d'ailleurs bien expliqué dans l'article de wikipedia. Si tu considères la chaine de caractères qui représente l'algo (en général, on fait plutôt ça avec des nombres, et en numérottant l'ensemble des machines de turing possibles, mais bon, c'est un détail), tu n'as pas besoin de lui passer des paramêtres pour que ça ai un sens.

> Mais les débats sur l'aspect libre de telle ou telle licence ne rendent elles pas
> la question du libre encore plus obscure et confuse ?

Attention, il ne s'agit pas de l'ensemble du mouvement du LL, juste d'une distribution. C'est bien qu'il y ai au moins une distribution qui se pose vraiment les questions sur ce qui est libre et ce qui ne l'est pas, ce qui est acceptable et ce qui ne l'est pas. Ca peut faire bouger les développeurs qui font du "prèsque libre".

Maintenant, si ça devient une priorité au point de retarder la sortie de plus d'un an par rapport aux objectifs, ca devient très dommage. Debian risque de perdre pas mal d'utilisateurs, et ça ne va pas franchement augmenter l'impact de ses actions.

> De toute manière, il faut être naïf pour croire que 6 personnes inconnues à l'autre
> bout du monde seront forcément plus productives qu'une personne recrutée de
> visu dans tes locaux.

Ben, le problème avec les indiens, c'est que si tu as fait un minimum d'effort pour pas recruter une tarre, le mec peut tout à fait être meilleur en info qu'un français, et vu que c'est dans ses traditions locales de travailler 50 à 60 heures par semaines ...

Un PC coute à peu près le même prix à Paris et à Bangalore.

En fait, tous les produits importés des pays occidentaux coutent à peu près le même prix à Paris et à Bangalore. (Un peu moins cher là bas, mais de peu)

Pour les produits locaux et la main d'oeuvre, il faut compter un rapport de 6 à peu près.

C'est le cas pour un certain nombre de projets.

Maintenant, si Torvalds s'était contenté de quelques heures de temps libre par semaine pour développer Linux, on n'en serait pas là.

La plupart des gros projets libres (GCC, kernel Linux, Gnome, ...) sont développés en grande partie par des grosses boites, et font intervenir des gros sous.

(J'ai bien dit la plupart, il y a des contres-exemples)

Le nombre de poste par élève a du passer de 0,25 à 0,33. Il a donc augmenté, et la phrase d'origine est donc correcte (Mais tirée par les cheveux !) ;-)