bmc a écrit 1651 commentaires

Sawfish ?

Tiens, ça serait pas mal ça. Ça peut se streamer le MPEG-4/XviD, enfin est-ce qu'il y a un moyen de streamer tout ce bazar ? Si oui, le son serait-il inclus dans XviD ou bien peut-il être contenu dans un stream Ogg Vorbis ?
Ça n'est pas très clair pour moi tout ça, c'est peut être pour ça que ma question est totalement confuse :-)

Mandrake est, quoi qu'on en dise, quand même nettement moins importante que le crédit Lyonnais ou FT en terme de poids financier, poids boursier, et nombre d'employés.

Si FT s'écroule, les télécommunications en France ça risque quand même d'être le bordel pour un petit moment.
Si le Crédit Lyonnais s'écroule, que vont devenir tous ses clients qui ont l'argent bloqué dans ses caisses ?
Si Mandrake s'écroule, il n'y aura absolument aucun impact financier et très peu d'impact sur l'emploi.

Évidemment, il faudrait beaucoup moins de liquidités pour redresser Mandrake que FT, mais FT est une entreprise stratégique pour la France. Qu'on approuve ou pas, ça ne change rien.

On retrouve d'ailleurs certains membres de l'IRIS dans l'EDRi, notamment Meryem Marzouki. Le monde est petit :-)

http://www.iris.sgdg.org/iris/bureau.html(...)
http://www.edri.org/cgi-bin/index?funktion=board(...)

Je sais que ogg123 et xmms le permettent.

Si je ne me trompe pas, la relative lenteur des connexions réseau entre un client et un serveur ont pour effet de monopoliser des ressources (buffers IP et TCP en cas de connexion TCP) qui ne pourront pas, pendant toute la durée de ladite connexion, être utilisée pour autre chose. Avec la même machine, tu pourras très bien supporter la charge (je ne sais pas si le terme est approprié) sur un réseau non saturé, et ne pas la supporter sur un réseau saturé (alors même que les machines recoivent moins de connexions, mais de plus longue durée), ta mémoire arrivant à saturation. L'argument disant que la lenter des connexions venant de chez Wanadoo créait un DoS géant, même s'il peut paraître éxagéré, n'est pas forcément faux. Voilà ce que j'en ai compris, merci de me corriger le cas échéant.

la rapidité du lisp...

Je confirme, il est excellent, très léger, très rapide. Par contre, il aurait besoin d'une base d'utilisateurs plus large pour se faire un nom...

http://www-asim.lip6.fr/alliance/(...)

C'est assez complet, mais aussi assez obscur et difficile d'accès. Intégration pas excellente, mais ça a le mérite d'exister et de marcher pas mal du tout.

Coucou aussi :)

Ksss ksss
je préfère faire confiance à Auré. S'il courrielle aussi bien qu'il nous fait des paquets Debian gftp aux petits oignons, le choix est vite fait ! ;-)

/usr/bin/ldd du paquet libc6 sous Debian. À moins que j'aie rien compris à ta question :-)

Le noyau Windows par défaut contient bien plus de code qu'un noyau Linux (au moins celui que tu te compiles toi-même une froide soirée d'hiver). Qui dit moins de code dit moins de bug (a priori bien sûr), d'autant plus quand ce code est ouvert et accessible à tous.

Alors si tu veux convaincre des gens que Windows est plus/moins/autant stable que Linux ou tout autre système d'exploitation, je te remercie de bien vouloir argumenter. Parce que la "stricte vérité" est en réalité un argument bien faible. As-tu fait un audit du code source des deux noyaux ? As-tu effectué des tests pour prouver ce que tu avances ?

Maintenant, si ce n'est pas le cas, je pense que tu ne m'en voudras pas d'affirmer que ta contribution est inutile :-)

Personnellement, je ne me permets pas de dire que tel OS est plus/moins/autant stable qu'un autre, tout dépend des conditions d'utilisation et du public visé par l'OS en question.
J'ai bien sûr moi-même rencontré des plantages de Linux, dû à 90% à cette m***e de XFree qui me fait étrangement penser à Netscape à une certaine époque : tout le monde déteste, mais on l'utilise parce qu'on a rien d'équivalent à se mettre sous la dent; les 10% restant étant soit des problèmes matériels, soit des tentatives monstrueuses de bidouillage du noyau :)
J'ai également rencontré des plantages sous Windows, sous 98 comme sous 2000 (même s'ils ont été bien plus rares sous ce dernier) dont les sources (sans jeu de mot ;) sont les biens connus vxd et dll, si je les trouve ces enfoirés je leur fais la peau.

Ouais, ça peut être pratique, mais là ton exemple est mal choisi, parce que libpng.so.3, ça me fait fortement penser à libpng.
Or:
# apt-cache search libpng
libpng-dev - PNG library - development
libpng2 - PNG library - runtime
libpng2-dev - PNG library - development
libpng3 - PNG library - runtime
#

Donc, je veux bien que ce soit utile, surtout dans le cas des librairies, mais avec la Debian, j'ai oublié toute cette histoire de .so.3.0.1.2.3

C'est sûr qu'on peut s'attendre à voir nos Sid toutes cassées pendant quelque temps par des packageurs frustrés et sanguinaires !
PH34R

En effet, je ne trouve pas non plus qu'il ait fait de son mieux sur ce coup, mais c'est un type très sympa par ailleurs, je pense qu'il est assez mal perçu et à tort.
Enfin bref, je ne suis pas venu ici pour troller vsFTPd contre PureFTPd, donc -1 :)

Ah au fait, PureFTPd a un grand nombre de fonctions, c'est exact, mais elles sont pour la plupart activables/désactivables soit à la compilation soit à l'exécution.
J'avais testé vsFTPd un jour, et je n'avais pas trouvé de support Postgresql. Comme c'est quelquechose dont j'ai besoin, j'étais resté sous PureFTPd, même si l' "esprit" de vsFTPd me paraissait intéressant.
Bien sûr il supporte PAM, mais je trouve ça moins pratique...

Pureftpd a aussi une option "humour" désactivable au ./configure :)
Et il est au moins aussi sûr, par contre niveau code source je ne peux pas dire.

Ouai, Jussieu roulaize. Mais bon, ils ont un bon paquet de machines en dual-boot quand même, z'ont pas encore tout passé sous Linux :)
Quant aux iMac des secrétaires, là faut pas trop compter à ce que ça change sous peine de grève générale ("comment ça je vais plus avoir ma souris translucide ?!").

-1, parce que le fil le vaut bien (et moi zossi d'ailleurs)

Sniff, il compile pas sur le paquet mozilla 1.0.0-1 de la Sid.
C'est moi ou c'est pour tout le monde pareil ? De sombres messages d'erreurs de g++...

Alors tous en coeur:
merci djrom !
merci amaury !

merci les dev de mozilla, merci les beta testeurs, merci aussi les testeurs intelligents, bref merci tout le monde.

Snif, j'en ai la larme à l'oeil.

\o/

Si c'est exactement ça. Merci :)
Les comparaisons sont ici:
http://www.bagley.org/~doug/shootout/craps.shtml(...)

Bien sûr, comme le dit l'auteur, c'est "just for fun"...

C'est exact, il ne supporte pas les traditionnels MBOX, mais il fonctionne farpaitement avec les MAILDIR, j'en suis très content. Avec un petit courier-authdaemon et courier-authmysql, c'est très pratique pour lier un webmail à un site avec utilisateurs autentifiés sans avoir à s'authentifier spécialement pour le webmail.

Ocaml, niveau performance, n'a pas grand chose à envier au C.
Bien sûr, un code C optimisé aux petits soins sera toujours plus rapide, mais la perte de performance est minime.
J'étais tombé sur des mesures de performances (bien sûr, elles valent ce qu'elles valent...) comparant la plupart des langages répandus en fonction des différentes tâches et algorithmes; résultat global, le C finissait premier, devant (dans l'ordre) Ocaml et C++...
Bref, je ne pense pas qu'on puisse dire que les performances de Ocaml (pour Haskell je ne sais pas, pour le Perl j'admets qu'il soit plus lent) soient un frein à son adoption pour l'écriture de logiciels dont les performances ne peuvent être sacrifiées, d'autant plus que le fait que Ocaml dispose d'un interpréteur et d'un compilateur facilite AMHA grandement le développement...

Faut dire que là c'est un peu mérité quand même... publier un programme comme ça et en avertir la terre entière alors qu'il n'est pas du tout stable, on a vu mieux comme façon de prouver qu'on est pas aussi mauvais que ce que croit le peuple :)

Même chose. Après avoir tracé le programme avec strace, je me suis aperçu que cela arrivait juste après un appel à socket(), qui retournait -EPERM. Sans regarder le code, j'en ai déduit que l'auteur ne testait pas le retour de l'appel système... pas très sérieux tout ça (si c'est bien le cas) :-)

Il aurait été plus sage AMHA de peaufiner un peu le code. Sinon, ça a l'air prometteur.