mister popo ポポ a écrit 77 commentaires

Les nosqls sont essentiellement basé sur les recherches en map-reduce ce qui correspond bien a des besoins pour des gros volumes et des données dispersés sur un cluster.
Redis a une approche inverse, il commence juste à s'attaquer au cluster, mais il est conçu pour faire des opérations atomiques et simple, avec même la notion d'effectuer de manière atomique une série d'actions. Au fil du temps, il a gagné la notion de pubsub, et il est utilisé comme queue de traitement (resqueue par exemple).
Pour moi, Redis est plus comparable à un index (comme Lucene) qu'un serveur SQL. Dans tous les cas, c'est un projet à suivre, ne serait-ce que pour son approche différente.

Redishttp permet d'avoir du code javascript 100% coté client, avec de la persistance (coté serveur).

http://docs.drizzle.org/mysql_differences.html#network-protocol

Drizzle parle le dialecte mysql, par contre, il prends le parti pris d'ignorer les commandes qui lui paraissent débiles (comme passer plusieurs commandes d'un coup, avec des ; comme séparateur, ou des types d'objets qui pinaillent). Donc, concrètement, les drivers sont compatible, mais pas forcément le code.

L'idée de brancher postfix (enfin, surtout dovecot) sur une base de donnée est d'avoir un serveur central pour toutes ses authentifications. Si on aime pas LDAP, ce que je comprends, le plus simple est d'utiliser une base de donnée relationnelle. Postgres, dans ce cas, permet d'utiliser une vue pour rajouter simplement une règle métier avant de confier la liste des comptes à Postfix. Là, l'idée de coller Redis est séduisante, il faut voir pour relier les autres authentifications sur ce même Redis. Postfix sait utiliser les bases de données simplissimes que sont les dbm.

Pour avoir besoin de scaler un serveur http statique, il faut taper TRES, TRES fort. La première réponse est de passer au CDN, et donc à la répartition géographique. Ce qui passe par le DNS.
Vouloir scaler un serveur http est une mauvaise idée.
Pour du dynamique, il suffit d'avoir un serveur en front, et des workers derrière en fastcgi ou même en http.

Franchement, si on veut un truc plus hype que lighty/nginx/cherokee, mongrel2 est bien plus interessant que ce soft de vieux con.

Pour moi, le coup des 30 petits logiciels pour faire tourner une appli, ça fait penser à toute la stack qu'il faut pour faire tourner un serveur mail. Avoir des besoins différents à part (l'imap, l'antivirus) me semble sain. Mais tout le merdier disparate pour l'antispam me semble bien reloud.

le javascript est normalisé sous le nom de ECMAscript, lors du développement de Chrome et donc de V8, Google a fournit des tests unitaires, qui ont été utilisé par Firefox, il me semble.

Dans tous les cas, la vrai différence entre les navigateurs webs, ce n'est pas la couche basse de javascript, mais le DOM et les APIs qui vont dessus. Perso, je fait du nodejs avec la doc mozilla, et je n'ai pas encore eut de soucis.

Il existe des projets node qui tournent aussi dans un browser, mais bon, le but d'un code fait pour node est de tourner avec node.

et en intel64, aussi, mais point de powerpc.

A la différence de twisted, qui bosse avec du python classique, node repose sur une API toute asynchrone. L'idée est d'avoir plein de petites taches sans attentes, ce qui facilite l'ordonnancement. Node supporte très bien les actions en parralèles, mais le support des multiCPU est pour l'instantt rustique. Les outils de bases sont en C/C++ et javascript sert juste de liant, un peu comme PHP, l'approche inverse de Python/Java.
Pour arriver à gérer tout ça sans s'emmêler les pinceaux, il y a les callbacks : les fonctions anonymes que javascript aime tant, et les events. On se retrouve à faire de la programmation fonctionnelle, avec des fonctions en cascade, et non plus de la programmation linéaire.

C'est compilé avec V8. V8 gère du javascript standard, à priori le même que gecko. Je ne comprends pas la question.

C'est marrant, la ressemblance de la conf de nginx avec celle d'Apache est vu comme un plus. Pour moi, la conf d'Apache est un echec industriel, plutôt XML, mais pas complètement, plutôt modulaire, mais pas complètement.
Je suis passé à lighttpd pour avoir des fichiers de confs lisibles, et en prime, j'ai gagné les performances du serveur monothread. La possibilité d'utiliser Lua pour les cas bizarres est aussi appréciable. Par contre, il est clair que le projet est en phase tranquille, avec des mises à jour de sécurité et pas beaucoup de buzz.
Sur ce point, Nginx est bien plus tonique. Aprés, le format de fichier, c'est pas du sendmail, hein, c'est lisible et bien documenté, et on arrive à quelque chose sans aspirine.

Le vrai bonus pour ces serveurs (nginx/lighty/cherokee), c'est qu'ils ont sorti le PHP, et que l'on peut utiliser php-fpm (spawn-fcgi était juste une béquille en attendant que fpm arrive). Avec php-fpm, on peut border bien comme il faut son site PHP, en isolant les utilisateurs ou même les restrictions timeout/mémoire par pattern d'url. Le tout, sans jamais attaquer le swap et en tenant des charges bien honorables.

que nenni, ce n'est point un troll, je suis aussi polyglote, et j'ai plaisir à découvrir de nouveau trucs. Juste que Go a été crée suite a un défaut de conception de Python. C'est donc paradoxal de dire que python lave plus blanc, alors qu'il a déclenché la naissance de Go.

Paf, en plein dedans.

Python fait parti des langages "officiels" de Google, avec C++ et Java, ils ont même Mr Python qui bosse chez eux : Guido Von Rossum. Google App Engine est d'abord sorti en python, comme autre exemple.
Sauf que Python, que j'aime beaucoup a UN problème, il gère les threads comme une bouse. Ca existe, mais il y a un gros lock qui pourri les performances. Tu peux avoir des taches en parallèle, mais pas profiter de la puissance d'une architecture multicore. Antoine Pitrou a proposé des patchs pour corriger ça, mais ça ne semble pas encore être le nirvana.

L'idée de Go est d'avoir un langage qui ne soit pas chiant à compiler (comme C++), mais qui gère les multicore comme il faut (pas comme Python).

Bon, je l'avoue, je n'ai pas testé Plone recemment, mais, ce n'etait pas l'impression de vitesse qui m'a impressioné. L'approche tout objet avec la base magique, les templates étranges, le python, je peux comprendre que ça plaise, mais je ne suis jamais arrivé à obtenir quelque chose d'utilisable. Je dois être pertverti par php ou les projets comme tornado, qui ont des approches plus contemporaine.

Je m'étonne aussi de la proposition d'utiliser apache mod_proxy, soit on veut utiliser un serveur léger pour gérer le statique et on utiliser lighttpd/ngnix/cherokee, soit on veut du cache pour décharger le serveur qui pédale derrière, et là, c'est du varnish.

J'ai du rater quelque chose.

c'est ballot de pinailler sur les majuscules en début de phrase ou les - pour trouver saint-glinglin. Faire une recherche qui fonctionne avec des orthographes de cochons est un poil complexe, mais tout passer en minuscule et remplacer les - par des espaces avant de lancer la recherche simplifierai la saisie, non?

Le coté propre et pro est agréablement surprenant.

C'est très pratique pour les scanners, par exemple. Les scanners sont bien plus précis qu'un appareil photo numérique, les données au dela des 8 bits sont donc pertinentes.
Le cas classique est le scan de diapositives mal exposées. Tu scannes, et ensuite, ton logiciel et permet de piocher dans les 10 ou 12 bits d'informations pour arriver à construire une image correct sur 8 bits. Avec plein de bits, on peut sauver un contre jour, par exemple, qui est à la fois trop clair et trop sombre.
Pas besoin d'être pro pour ça.

La version précédente de RoR avait un problème rédhibitoire, le serveur était mono threadé. Donc, pour bosser et faire une démo qui impressionne, ça passe, sinon, ça devient de suite plus compliqué. Il faut lancer tout un tas de serveur, et utiliser un serveur web comme lighttpd qui fait du roundrobin sur tout ça. Du cluster sur une seul machine. J'ai peut être pas les yeux en face des trous, mais je n'ai pas vu si la version 2 corrige ce problème.

Autre problème, RoR est une application, sans possibilités de contraindre simplement l'utilisation mémoire ou le temps maxi pour exécuter une page, ce qui le rends inutilisable sur un hébergement mutualisé dans le genre de Free.

Autre fantasme, la migration d'un site en PHP qui va bien mais pas joli, vers du RoR qui rulez. Il y a eu récemment un post sur SlashDot sur ce sujet. Le type avait embauché un des dev de RoR pour faire la migration, et au bout de 2 ans, ils ont jeté l'éponge. RoR est un logiciel de prototypage, très bien pour créer from scratch un site, et surtout pas quelque chose vers quoi migrer.

La gestion des sessions en Cookie, comme évolution me parait tout simplement risible. La taille des cookie est limité, et les logiciels civilisé savent gerer les sessions en RAM, sauf si ils sont en cluster ou il faut passer à quelque chose de de suite nettement plus compliqué. PHP a le bon de laisser l'admin s'occuper du choix, sans faire passer une astuce pour une évolution.

La qualité indéniable de RoR est d'être un aiguillon pour tous les autres, il n'y a qu'a voir l'arrivé de Grail, PHPCake ou Django. Un serveur peut être simple, et le volume des fichiers de configurations ne doit pas dépasser le volume de code. Le MVC, l'ORM, l'intégration d'un framework JS, un outil de build, le REST et JSON font maintenant parti des ingrédients d'un bon framework web.

Il existe des patchs pour distcc pour utiliser zeroconf, c'est rigolo cette fascination pour le serveur centrale sous Linux.
Avahi, le maitre du zeroconf sous Linux propose même des lib de compatibilité pour les projets developpé avec howl ou autre implementation zeroconf. Donc, plutot que d'utiliser un serveur centrale qui compile pas, un bon zeroconf me semble plus sain.

ça, c'est la definition de SQLite. Berkeley DB, c'est une table de hachage avec persistance. On stock juste des clefs/valeurs. Ya pas de relations ou de SQL, c'est plutot primaire, et c'est pour ça que ça sert de base à des applications comme openLdap. Mais par contre, c'est super rapide.

vgetty : http://alpha.greenie.net/vgetty/(...)
ncid: http://ncid.sourceforge.net/(...)

ncid, c'est juste pour intercepter l'identifiant de l'appelant. Vgetty, c'est le répondeur avec tout plein de trucs.
Par contre, il faut des vrais modems, pas des trucs cheapos qui n'implémente pas toute la norme. Olitec, pour rester chauvin, qui a le bon gout d'indiquer sur son site les chaines d'initialisation.

par ce que la gestion des droits sur NFS est reloud.
par ce que NFS, il faut utiliser le logiciel "NFS Manager" pour faire des réglages sans se battre avec Netinfo.
Par ce qu'avec Howl (du rendez vous) ton partage peut être vu spontanement par tes macs sans rien configurer.
Donc oui, c'est une bonne nouvelle pour les maqueux.

La solution passe aspell ou pspell. Sois tyu utilises une library qui gère l'interface pythpn->pspell, sois ton python utilises l'application en ligne de commandes.
Spip 1.8 utilises un serveur d'orthographe, avec un protocole en XML.
Tu as le code et les infos sur : http://lab.spip.net/spikini/CorrecteurOrthographique(...)

et achètes en une autre. Un modèle plus durable.

en fait, le plus simple est de paser par graphviz. Un parser genere un graphe .dot, et ensuite graphviz s'enquiquine à l'afficher joliement.
Ce qui est embetant, c'est mysql ne gérant pas les clefs étrangères, il faut utiliser une astuce de nomencalture (du genre id_matableetrangere) pour que le parser s'y retrouve.

et voila, ya un truc qui existe :
http://sqlfairy.sourceforge.net/(...)

et voici un screenshot qui va bien :
http://sqlfairy.sourceforge.net/images/graphviz.png(...)

http://www.neokraft.net/blog/2004/07/20/532-cesser-de-mentir(...)

C'est dommage, les commentaires ont été sucrés, mais c'etait un excelent post de déprimé.

> 1- L'administrateur système n'a trouvé aucun equivalent sous Linux
> de Windows RDP (Accès bureau à distance, pour controler et installer
> des applis...) sous Xfree on est obligé d'ouvrir une autre session X et
> non pas utiliser directememt la session Xfree de l'utilisateur.

pour les installs, ça devrait marcher en SSH, et pour la prise de controle VNC est ton ami.
Le projet Vino ( http://www.gnome.org/~markmc/remote-desktop.html(...) ) pour Gnome est un emballage pour VNC pour montrer à l'utilisateur une manip à distance.

L'url a bougée :
http://www.gnome.org/~jdub/debian/(...)