Joris Dedieu a écrit 1614 commentaires

Au final, j'ai fini par choisir HTTP.

Je comprends bien ce choix de HTTP. Par contre le pingback que tu proposes montre a quel point il est inadapté à ce type d'échanges.

Ce n'est pas spécifique à ton projet.

Sans même parler de sa mauvaise utilisation (requêtes get a effet de bord, sous utilisation de mime), de ses bidouilles (keepalive ...), on voit clairement qu'on passe son temps a faire des requêtes http dans tous les sens en se demandant si petit scarabée est bien celui qu'il dit qu'il est ; côté serveur (auth bypass, vols de sessions ...) comme côté client (phishing ...).

La solution n'est pas de commencer par réfléchir a un protocole fiable pour ouvrir des sessions chiffrées et authentifiés. Puis transporter le reste après.

Pour mémoire skype est une gros utilisateur de postgresql. Je ne sais pas exactement
ce qu'ils contribuent (deux contributeurs officiels) mais il me semble qu'ils ont bien poussé sur les solutions de clustering et certaines problématiques.

Justement, quel type de concessions ?

Il faut penser que c'est un OS principalement serveur. Il y aura plus de travail sur le support des cartes raid que des dungle dvb.

Le support du materiel est relativement uniforme sur l'ensemble des *BSD. Il y a une façon d'écrire le code, un soucie de stabilité dans les appels systèmes, une tradition qui fait que le code est porté facilement (y compris vers d'autres OS qui n'ont rien a voir).

DragonFlyBSD est plutot stable (je l'utilise en production sur des machines bien critiques et elles me foutent un paix royale). Par contre les devs veulent avancer vite sur certains points et ont des priorités bien claires. Tu peux donc avoir un truc annexe qui pète d'une version a l'autre sans prevenir (exemple http://bugs.dragonflybsd.org/issue1848 )

Ça c'est un de mes vieux rêves,
Sous DragonFlyBSD ça s'appelle swapcache. L'idée est de faire du ssd un espace de cache rapide et fiable. Des tests ont été fait avec du postgresql dans une configuration forçant volontairement beaucoup d'io. Les performances sont multipliées par 5.

Voir :
http://www.dragonflybsd.org/docs/howtos/swapcache/
http://leaf.dragonflybsd.org/cgi/web-man?command=swapcache&section8
http://www.shiningsilence.com/dbsdlog/2011/04/12/7586.html

zfs supporte la déduplication sous solaris et sous FreeBSD
http://svnweb.freebsd.org/base?view=revision&revision=219089

Cependant, pour d'autres fichiers de configuration, il n'existe aucune standardisation ce qui nous a forcé à introduire une orgie de #ifdef dans notre source afin de pouvoir interagir avec les différents emplacements utilisés par les distributions.

Faire un fichier de configuration n'était pas envisageable ?

Je n'ai rien contre l'évolution et la standardisation attention. Mais ici le prétexte est clairement fallacieux.

Mes deux cents
Joris

Tant qu'à faire, autant utiliser Jabber partout :-)

Et pas l'inverse bien sûr. Utiliser l'irc pour piloter des serveurs (fussent-ils virtuels) ça fait mauvais genre.

Tu gagnes bien plus que ça si tu as des système de fichiers sur le réseau.

Si ton système de fichier réseau contient ta racine, tu l'attendra de toute façon. S'il contient des données, il ne sert a rien de l'attendre et dans ce cas une modification du script d'init est sans doute moins intrusive.

Qu'en est-il des autres Unix comme les *BSD?

Ils ont échappés a /sys voir même à /proc (pour les meilleurs d'entre eux :) ils échapperons bien à /run. Les autres Unix libres ne sont pas concernés parce qu'ils montent leurs fs avant de lancer des services ce qui semble être l'ordre naturel des choses.

ça doit aussi faire sourir IBM qui n'a jamais réussi à vendre son processeur CELL ailleurs que dans la PS3

A bon ? Moi il me semble qu'ils n'ont jamais essayé. Annoncer ça oui, mais en proposer hors des plateforme de dev, j'ai jamais vu. J'ai le sentiment que même le sparc est mieux commercialisé :) c'est dire

Balance !!! c'est secret comme projet et pas encore fini du tout et rien d'officiel du tout pour le moment :)

Remarque que j'aurais pu mettre un lien direct vers le repo :)

Mais pourquoi ne pas fournir une gestion des paquets plus avancée que cd /chemin/paquet && make install ?

En fait ça dépend de ce que tu veux faire. pkg_add, le gestionnaire de paquet binaires et un peu léger pour être un apt like.

Je dirais que pour une machine configuré aux petits oignons, les ports sont excellent et te permettent dans la plus part des cas d’exprimer ce que tu souhaite faire. Pour un parc la solution la plus propre est de générer des packages à partir des ports (make package-recursive) puis de les déployer avec pkg_add. Cela te permet de gérer tes mises à jour finement sans trop se prendre la tête. Par contre pour quelqu'un qui veut quelque chose plug and play a la apt, il y a clairement un manque.

C'est comme beaucoup de choses sous FreeBSD (et dans le libre), tant que personne n'y trouvera un intérêt suffisant ce ne sera pas fait (pour les packages, je crois que bapt http://blog.etoilebsd.net/ est plus ou moins sur le coup). Un autre exemple est le vénérable installateur (sysinstall) visiblement, il va enfin être réécrit. Tout le monde dit qu'il manque ci ou ça, ceci dit si je prends mon exemple personnel, je ne l'utilise que très peu et pour faire pas grand chose. Je pense que c'est le cas de beaucoup. La bonne façon d'aborder les problèmes sous FreeBSD avant de dire que saynul y pas aptitude, c'est d'essayer de comprendre comment font les gens. Si l'outil n'est pas là, c'est souvent qu'il existe une autre façon de faire et en général elle est maline et pratique.

Voili voilà. Un exemple ? le plus "célèbre" : http://www.ixsystems.com Mais bien d'autres existent. Ainsi que des ISV d'ailleurs.

personnellement, j'aurais dis netapp

Une version sur deux (a peu pres) a un support étendu sous FreeBSD. Voir http://www.freebsd.org/security/security.html#sup .

De plus la compatibilité binaire est complète entre les versions de chaque branche (si tu passe de 7.3 a 7.4 tu n'as pas besoin de recompiler tes ports). Lorsque tu choisi une version majeure (aujourd'hui la 8 par exemple), tu es tranquille pour au moins 5 ou 6 ans.

Enfin il existe des modules de compatibilité binaire pour chaque version non maintenue. Ainsi un binaire compilé sous FreeBSD 4 pourra fonctionner sous FreeBSD 8 (sous reserve d'installer la compat 4x).

Bonjour,

Je pense qu'il faut que tu prenne rapidement contact avec un élu. Tu devrais également donner un cadre légal a ton site (association ...).

k.mx.mail.yahoo.com. smtp
Trying 98.139.54.60...
Connected to k.mx.mail.yahoo.com.
Escape character is '^]'.
420 Resources unavailable temporarily. Please try later (mta1206.mail.ac4.yahoo.com)
Connection closed by foreign host.

Vous savez ils ont plein d'autres serveurs :)

>Je résous ce problème avec l'add-on Randomuseragent (modifié).
sinon "`fortune | tr -s '\n' ' '`" marche bien

http://leaf.dragonflybsd.org/cgi/web-man?command=swapcache

>Ah, et théo a posté un mail qui démystifie un peu le FUD..

Tu veux dire que c'est l'arroseur arrosé :
(h) If those were written, I don't believe they made it into our
tree. They might have been deployed as their own product.

>est aussi un coup marketing mené par des entreprises qui veulent "en croquer"

Je ne pense pas que RedHat se serait mis dans un truc rien que pour faire du buzz. Ce n'est pas le genre.

Je ne vais pas crier à l'injustice mais mes 20 avis passent à 5 sur la nouvelle version. J'imagine donc que le système de karma a été revu en profondeur.

Qu'en est-il exactement ?

>Est-ce qu'on ne tombe pas sur trop de ports qui utilisent des gccismes ?
De toute façon l'objectif à court terme est de proposer les deux compilateurs. FreeBSD prends beaucoup de soin de pour ne pas casser la compatibilité binaire entre les versions.

Un programme compilé pour FreeBSD 4.11 fonctionne encore aujourd'hui (moyennant l'installation d'un couche de compatibilité). Outre pour certains programmes propriétaires (comme le kit de paiement sips-atos par exemple), cette particularité permet une incroyable souplesse pour monter en version sur des machines en production.

>Qu'est ce qui empêche le spammeur de signer ses emails ?

Je pense que "aurait pu" t'a échappé dans mon propos.

Imaginons quatre règles simples et universellement adoptées (puisqu'on est dans le conditionnel passé qui n'aura jamais lieu) :
- tout possesseur de domaine est identifié par une clé
- tout utilisateur d'adresses @ledomaines est identifiée par une sous-clé de celle du domaine
- tout domaine ne peut révoquer sa clé que tous les 5 ans
- tout mail non signé est rejeté.

les clé des spammeurs sont blacklistées en trois jours chrono. Chacun prends ses responsabilités. Tous le monde (imagine la clé de orange.fr blacklisté) demande un minimum de garantie avant d'ouvrir son smtp. Même yahoo finirait par faire du ménage dans ses groupes de discussion.
Fin du spam.

Mes deux cents
Joris

Crypto ... crypto-communiste s'il te plais !

>Ah bon? Tu gères comment le cas de la personne qui cherche à prendre contact avec toi par mail?

Je ne vois pas la difficulté. Elle signe son mail, je récupère sa clé sur un serveur de clé. Je lui répond en en signant mon mail et elle récupère ma clé sur un serveur de clé ...