Matthieu Moy a écrit 3255 commentaires

Prétextant que l'initiative dunc-tank n'est pas affiliée au projet, il a complètement éludé toute discussion, et imposé son idée.

Un tel comportement — en particulier de la part du Project Leader — est naturellement propice à se poser des questions quant à la capacité de celui-ci de représenter le Projet.

Tu ne voit toujours que des faits ?? Moi, j'y voit quand même plutôt une attaque en règle du DLP ...

Arf, c'était donc pour ça que mes étudiants me parlaient comme ça en sortant de leur partiel hier ?

Euh, le purin d'orties ?

C'est quand même un truc qu'on utilise depuis des siècles sans problème. Si on se rend compte qu'il y avait des effets secondaires et qu'il faut l'interdir, soit, mais ce n'est absoluement pas le cas ici.

Le mec en question, tout ce qu'il a fait de « mal », c'est d'écrire un bouquin et d'organiser des stages de formation sur une tradition ancestrale. C'est pas comme si c'était un truc qui datait d'hier et qu'il le vendait sans autorisation.

Si je comprends bien, les mendiants dans la rue, tu sais qu'ils ont besoin de ton pognon, mais tu veux pas leur donner quand même.

Pour ta gouverne, y'a quand même pas mal de gens qui donnent bien plus que 20 euros par mois aux restau du coeur ou autres. Pour eux, la bonne conscience coûte visiblement un peu plus cher que pour toi.

J'allais faire une blague sur la possibilité que la mise à jour te casse X.org et que tu passes une nuit blanche, mais je me suis dit que c'était un peu lourd.

Je me retiens donc.

Bon, j'avais pas mis de smiley, mais je vais réparer ça au cas où :

« ;-) »

Mais pour le problème de fond qu'il y a derrière, oui, je suis en SID, (fier de l'être ;-) ), et je prends le risque d'avoir des trucs qui pètent de temps en temps. Il faut croire que je touche du bois, parce que chez moi, j'ai rarement des mésaventures aussi graves qu'un X ou le réseau qui casse. Pour moi, le contrat entre moi et ma disrib, c'est « j'ai une distrib relativement à jour, que je considère de bonne qualité, et en échange, j'accepte que ça casse de temps en temps, et je fais des rapports de bug quand c'est le cas ».

Mais c'est clair que quand c'est une version stable qui casse, et quand c'est la première version d'une distrib qui insiste autant sur le support et la finition, ça fait effectivement tâche.

... je suis pas si mal en "unstable".

Toi aussi, tu lagues.

http://linuxfr.org/comments/754664.html#754664

Je peux me tromper, mais on m'a toujours dit que le caractère trois points était celui de la typographie anglaise, avec des points un peu plus rapprochés qu'en Français.

> J'ai pas dit le contraire mais bon il faut avouer que des fois lorsque les admins
> sont tres c.. ou feignant ou les 2, ca aide.

Tout à fait. C'est pour ça que skype a été conçu comme ça.

Mais je vais donner deux exemples : sur le réseau renater, Skype est explicitement interdit par le règlement. Questions de sécurité entre autre, bon, bref, qu'elle qu'en soit la raison, c'est interdit.

Et bah pourtant, même dans un labo avec un sysadmin compétent, les utilisateurs utilisent quand même Skype, parce que c'est un cauchemard à bloquer.

Autre exemple, en ce moment, je suis dans un institut avec une connexion qui rame comme pas possible, un proxy HTTP surchargé. Y'a des firewalls dans tous les sens, par exemple, même pas moyen de faire du CVS vers l'extérieur. Pratique pour les étudiants qui veulent travailler sur la dernière version d'un soft. Et bah malgré ça, Skype passe sans problème. Bah désolé, mais quand je dois attendre trois plombes qu'une page se charge pour le boulot et que je sais que sur le même serveur, y'a un mec en train de téléphoner à sa copine tranquilement, bah c'est pas cool.

> Euh tu es sur qu'il fait la video sous linux?

Ça, j'en sais rien !

Niveau firewall, c'est clair que Skype a l'avantage pour l'utilisateur.

Mais il faut voir aussi à quel prix : Skype, c'est un truc qui a été fait pour que les utilisateurs puissent emerder leurs administrateurs. Ça peut utiliser un proxy HTTP, ça passe sur le port 80 et le 443, ça fait du peer-to-peer si besoin. Du coup, c'est quasi impossible à bloquer.

Alors oui, pour l'utilisateur qui ne regarde pas plus loin que le bout de son nez, Skype, c'est super, mais heureusement qu'internet ne s'est pas construit comme ça. Elle est où la bonne époque où un numéro de port correspondait à un protocol, et où on pouvait comprendre facilement ce qu'il se passait sur un réseau ?

Sinon, skype marche aussi sous Linux (mais il est proprio aussi sous Linux ;-) ).

En l'occurence, le truc pas standard, c'est d'utiliser le caractère « trois petits points » en typographie française si je ne m'abuse.

Petit jeu : compares le commentaire auquel tu réponds au texte ci-dessous (devines d'où il vient) :


You are not required to accept this License, since you have not signed it. However, nothing else grants you permission to modify or distribute the Program or its derivative works. These actions are prohibited by law if you do not accept this License. Therefore, by modifying or distributing the Program (or any work based on the Program), you indicate your acceptance of this License to do so, and all its terms and conditions for copying, distributing or modifying the Program or works based on it.

Euh, oui, mais ça n'empêche pas le fait que si tu n'acceptes pas la GPL, tu n'as pas le droit de modifier ou de redistribuer le programme.

La GPL est libre, mais pas au point de ne pas avoir à l'accepter, ça n'a pas de sens.

Côté redirections, avant de découvrir zsh, j'avais :

* tcsh: pratique, mais incomplet. Dans 99% des cas, on redirige stdout, ou bien les deux, et là "toto.sh >& /dev/null" est hyper pratique

* (ba)sh: on peut tout faire (y compris ne rediriger que stderr), mais le 2>&1 > /dev/null est vraiment lourd.

et en zsh, y'a les deux syntaxes ;-).

En effet. Pour être plus précis, disons "malloc(100Mo); initialisation triviale à un truc arbitraire;" par exemple. Enfin, un truc qui bouffe 100Mo mais qui ne s'en sert pas ou pas souvent.

Euh, oui, je répondais à un message qui disait que l'avantage des processus, c'était de pouvoir utiliser plusieurs CPU. Et je répondais que les threads étaient faits pour ça.

Euh, déjà comme tu dis, c'est pas vraiment critique : de toutes façons, tes applets ne bouffent pas 100% de CPU, donc les context-switch, tu les aura de toutes façons.

Et à part ça, les threads, c'est fait pour ça aussi ! (l'avantage des processus séparés est surtout la stabilité : un applet qui segfault, ça ne fait pas planter les autres).

Attention : vitesse != consommation mémoire.

Tu prends une applie qui fait malloc(100Mo) et qui ne s'en sert jamais après. Elle prétends consommer 100Mo (enfin, au moins), et pourtant, tout ça va être swappé une bonne fois pour toute, et ça ne gènera pas la fluidité de la machine (c'est pas pour autant une bonne idée, mais bon).

Enfin, du coup, sur un système moderne, la question c'est pas tellement « combien » d'utilisation de mémoire, mais plutôt « comment ». Et c'est pas évident à mesurer surtout si on prétends être objectif !

Pour les ailes dans les murs, y'a quand même une explication assez simples : l'avion n'a pas forcément percuté le bâtiment à l'horizontale ...

http://pclinux.fr/ mais il est « en cours de refonte », et malheureusement, je crois que ça fait un moment. Dommage, c'était une bonne initiative.

Donc si je comprends bien, Mandrake, c'est mal parce que c'est pas libre, et qu'en plus y'a pas flash, c'est ça ?

> euh y'a pas moyen de dire à son gentil debugger de ... faire son break quand le segfault arrive?

Euh, c'est un peu le mode par défaut ...

Mais bug != segfault.

Et par ailleurs, en général, l'endroit intéressant, il est quelques instructions avant le segfault (genre « Grmbl, comment ça il est nul mon pointeur, je viens de l'initialiser ? Ah, en fait, non ! »).

http://www.google.com/search?q=%2246+heures+chrono%2C+plus+v(...)

Euh, les « time-based releases », c'est quand même un truc plutôt à la mode dans le libre en ce moment. Même Debian parle régulièrement de passer à ce modèle. GNOME, Ubuntu, Gentoo, pour n'en citer que quelques uns ont adopté ce modèle. Le noyau Linux n'en est pas très loin.

L'idée est qu'au lieu de dire « pour la prochaine release, on va mettre les fonctionalités X, Y et Z, on verra combien de temps ça prend », on dit « on va faire la prochaine release à telle date, on verra ce qu'on arrivera à mettre dedans ». Si on bosse intelligemment, on a des branches de développements, qui sont incluses dans la branche principale après avoir été un minimun testées, donc c'est raisonablement facile de garder un truc sur lequel des gens ont bossé pour la version suivante parce que ça n'était pas prêt.

Dans le cas particulier de Mandriva, après la release, il y a les CD à presser, les boites, ... j'imagine que tout est déjà organisé, et j'imagine que tout ça n'est pas évident à décaler en terme de calendrier. D'autant que bien sûr, il faut que tout ça soit prêt pour les courses de Noel. Oui, il faut vendre, c'est ce qui donne des sous pour payer les gens qui bosseront sur la version suivante.

(tout ceci étant dit, j'espère que si ils trouvent un bug vraiment critique le 14, ils repousseront la date !)