Sytoka Modon a écrit 4551 commentaires

Enfin, si tu veux un VM performante, tout ne tourne pas en simple utilisateur, trap système, réseau, etc. Ce genre de chose sont parfois cachés dans des sudo ou des binaires suid...

Personnellement, j'aime bien pour les << serveurs >> la technique de Xen sur debian qui consiste à faire une partition LVM pour chaque partition partition de la machine virtuelle. Ainsi, il n'y a pas de MBR, de table de partition... Il est très facile de réparer une machine virtuelle sur le serveur central.

L'aléatoire du nombre Pie n'est pas verbeux. A partir du moment ou l'on est verbeux, on est dans un langage (verbe) donc avec des mots, des phonèmes. Les règles statistiques des langues montrent bien que les phonèmes ne sont pas égales et que certaines reviennent bien plus souvent.

Donc, à mon sens, je suis assez d'accord pour dire que si un langage est verbeux, il devrait pouvoir un taux de compression important.

Moi, au boulot, ce sont les photocopieurs qui scannent donc plus de scanner !

Je vois pas trop l'intérêt d'un << scanner professionnel >> sauf dans le cadre d'un atelier de reprographie.

Il est évident qu'en réactivant le développement de Perl5, il y avait un risque pour Perl6. Cependant, en pratique, Perl6 est un autre langage et la communauté est d'accord pour dire qu'il aurait du changer de nom.

Perl6 a tout de même pas mal d'avantage sur le papier, donc je suis persuadé qu'une fois la première version stable sortis, les applications vont suivre petit à petit. Il est clair que les gros environnement sous Catalyst ne vont pas migrer en premier ;-)

H264 est sortie pour la visio-conférence car il y avait un besoin qualité / bande passante que n'avait pas le H263.

Les tarifs des équipements de visio : terminaux et ponts ont permit a ces entreprise de développer le H264. Même si les tarifs ont baissé, il faut voir ce qu'ils étaient plus de 5 ans en arrière...

Il avance bien. Je crois qu'il passe déjà plus de 30000 tests et il est prévu pour la fin de l'année (au mieux).

Mais comme le projet Perl6 a pris beaucoup de temps, le développement de Perl5 est repartis de plus belle et pompant pas mal d'idée dans Perl6.

Bref, Perl est loin d'être mort et bouge pas mal de tous les cotés ;-)

D'ailleurs, je mettrais plutôt "cette entreprise" que "la société" ce qui éviterait une répétition ;-)

Si on écrit une dépêche à charge, le mettre dans l'énoncé est à mon sens une bonne chose.

Sinon, ce n'est pas parce que les journalistes écrivent parfois (souvent) n'importe quoi qu'il faut se montrer aussi stupide qu'eux ;-)

Bref, soyons intelligent, soyons Humains !

J'avoue ne pas être fanatique du bonhomme mais être comme toi très surpris que cette dépêche soit passé tel quelle.

Cela aurait été au second dégréé, on aurait au moins rigolé. Présenté ainsi, cela fait vraiment attaque gratuite. Le propre de l'enquête anthropologique, c'est de faire une étude symétrique (cf Bruno Latour).

> seul sont interdit les protocoles de voip, ce qui se comprend.

Même cela je ne comprends pas !

A partir du moment ou tu as du web illimité, pourquoi interdire un protocole ? Le résultat va être la fabrication d'autres protocoles de type voix sur http pour passer au travers...

Bref, mauvais filtrage à mon sens

Et en plus, le CERN est interdit aux expériences militaires je crois me souvenir ;-) Bref, c'est du 100% civil.

CouchDB est programmé en Erlang alors que MongoDB semble être programmé en C++. N'est-ce pas le fait qu'Erlang soit un langage peu connu des programmeurs (comparé au C++) qui limite les capacités de développement de CouchDB par rapport à d'autres projets ?

Et bien moi, je reste un peu sur ma faim après la lecture de cette nouvelle. On aurait avoir des éléments du bilan, des pistes pour la suite du projet...

Je sais, il y a les liens mais un peu de rédaction dans la dépêche n'aurait pas fait de mal, bien au contraire pour le projet.

Si, parfait. Je n'avais pas encore pris le temps de faire un tour sur le CPAN avec Riak comme clef de recherche. Quel idiot !

http://search.cpan.org/dist/AnyEvent-Riak/lib/AnyEvent/Riak.(...)

Effectivement, ca a l'air sympa. Dommage, je ne vois pas le connecteur Perl mais quand je vois une API REST et j'ai parcouru le code pour php, je dois arriver à faire un module Perl minimal pour ce que je veux faire.

Merci

Mon datacenter (enfin, ma salle serveur) n'est pas loin de mon bureau et y aller une fois par mois n'est pas un exercice inutile ;-)

Le boot sur clef USB (LiveUSB ?) est aussi très rapide et très souple (il y a sur la clef tous les outils nécessaire). Sur les serveurs, le plus long est souvent la phase du bios...

Sinon, pourquoi veux tu te débarrasser de sudo ? Entre root et sudo, je préfère me débarrasser de root.

Je gère pas mal de machine et cela ne m'est arrivé qu'une fois en 4 ans. Et comme je n'avais pas le root de cette machine, j'ai mis un LiveCD de systemrescue et j'ai du viré le mot de passe !

Le coup de /bin/bash dans init marche très bien aussi et m'a servis plus souvent. En plus, rien à retenir ou presque ! La aussi, tu peux facilement virer le mot de passe sur root et rebooter un coup...

Bref, j'ai encore un mot de passe root sur mes machines mais je pense sérieusement à le virer dans un avenir proche pour me simplifier la tâche.

Je cherche une base de données clef-valeur persistante qui fonctionnerais en cluster avec que des maîtres, aucun esclave et gestion de la suppression et de l'ajout d'un noeud à chaud. En effet, je veux avoir n fois le même serveur et laisser la base de données répartie gérer le reste, sachant qu'il n'y a pas de problème s'il y quelques incohérences parfois dans la base (très peu probable).

J'ai fait un tour du sujet ce matin et je n'ai trouvé que des solutions maître-esclaves avec des systèmes compliqués pour changer de master (d'ailleurs, si mes souvenirs sont bons, Redis a déjà un script pour changer de master mais les clients ne savent pas le gérer de manière transparente).

A l'ère des nuages, je suis surpris par toutes ces nouvelles base de données qui au final ne sont pas très "cloud" je trouve.

Pas du tout. J'ai juste écrit que la grammaire Perl6 était écrite sous forme d'expression rationnelle. Ensuite, je parle de "Modern Perl" qui est plutôt un mouvement qui cherche à profiter des avancées sur Perl6 pour en intégrer dans Perl5 et qui de ce fait écrit du code Perl5 d'une autre manière...

Je ne parle donc pas de révolution mais d'évolution ;-)

Enfin, kif-kif c'est gentil.

Le NAT est une vrai daube pour les protocole un peu complexe comme le H323 ou le SIP... Donc pour essayer de faire marcher les bousins, on passe par des serveurs en IP publique et on perds une partie de l'esprit d'internet de faire du point à point mais surtout de faire simple.

Donc, oui le NAT n'apporte aucune sécurité supplémentaire et oui le NAT rend les choses bien plus complexe.

En fait, le NAT est une mauvaise invention qui nous a fait perdre 10 ans et qui aura complexifié inutilement toutes les applications réseaux.

Ca avance, ca avance !

Le jour ou Perl6 sortira, vous verrez combien Perl5 a évolué ces derniers temps (en restant compatible) et qu'il a bien profité de tout l'effort fournit sur Perl6 ;-)

Enfin, le C pourrait lui aussi évoluer sur ce sujet ;-)

J'ai jamais réussi à bidouiller correctement un serveur de mail sauf justement qpsmtpd car le code est lisible et même moi, j'ai réussit à modifier des greffons et à écrire les miens ;-)

De même, Email::Filter est un bonheur pour bidouiller les mails via le .forward. Au moins, tes filtres sont clairs et les possibilités proche du CPAN !

C'est juste deux exemples de petits trucs que j'ai du toucher ces derniers temps.

Lorsqu'en Perl, on met

m/toto.*?titi/

je crois me souvenir qu'il ne fait pas de référence arrière du fait du ? après l'étoile. Il y a aussi la variante avec le + à la place du ? mais je ne l'ai jamais utilisé.

Attention, ne me faites pas dire ce que je n'ai pas dis ! Je n'ai pas dis que Perl avait inventé les regex ! Je sais bien que cela vient en gros de ed et que cela a été repris dans awk, puis dans Perl.

Je parle de démocratisation à grande échelle. Ce n'est pas avec ed ni avec awk que les regex se sont démocratisées. D'ailleurs, la plupart des monolignes awk se résument à récupérer la colonne X..., chose qu'il fait très bien.

Sinon, j'évoque l'avenir des regex et je vois que du coté de Perl, les évolutions proposées en 15 ans sont énormes. J'ai l'impression que les autres langages suivent. C'est peut être juste une impression.