Mais au passage tu as complétement changé les specs de ce qu'il veut faire. Tu es passé d'un serveur web offrant les applications courantes déjà intégrées à un système de backup... Il n'y a pas de secret, si tu veux qu'un serveur web à l'autre bout de la planète serve tes données, alors il faut qu'il puisse les lire. Tu peux oublier tout le pan sécurité, chiffrement etc. Et ca ne s'appelle plus du HTTP/nav puisque il va falloir localiser les données (sauf gros hack dégueulasse avec service de localisation centralisé, HTTP redirect & co).
- Soit il y a un journal tout les deux jours sur google c'est le nouveau mal, et les gens n'ont plus grand chose à dire
- Soit les gens ne voient pas le problème que google utilise des documents dont les propriétaires ont donné leur permission pour une telle exploitation, et ont renseigné les géotag
- Soit les gens ne voient pas le problème que google fasse ce que flickr et tout les plateforme de publication de photo offrent depuis des années... Visualiser les photo géotagées sur une carte !
Sur ce coup la google ne fait rien de mal semble t-il. Ils exploitent les données que les services tierces et les propriétaires des documents ont bien voulu laisser exploitables (API publique, documents sous CC & co). Si tu mets des documents librement accessibles et utilisables, il ne faut pas venir se plaindre que quelqu'un les utilise...
Reste juste à virer à la main une fois les cookies flashs (LSO) et ça marche plutôt bien. Juste penser à ne pas cocher le partage d'info puisque ghostery a été revendu à better advertising.
Non mais tu es sur linuxfr. Le site ou tout le monde peut se permettre de donner des leçons aux équipes engineering des plus gros services du monde sur un coin de nappe entre midi et 2, par ce que eux ils savent (c).
Ebay c'est du Java (Ils utilisent que la partie "basse" de J2EE), Amazon c'est majoritairement du Java (Certains traitement sont en C++ ou Perl), linked-in c'est du Java (sauf la gestion du graphe), certains service yahoo c'est du java, orbitz aussi. Non vraiment y'a rien a dire Java ca marchera jamais, c'est pas efficace et y'a pas plus couteux en prod. Tout les gros s'en sont d'ailleurs aperçu, et ne contribuent absolument pas aux projets de la fondation Apache ;-)
C'est pas par ce que les SSII pondent des bouzes infâmes que Java c'est de la merde. C'est juste par ce qu'ils pondent des bouzes...
Et visiblement tu ne sais absolument pas de quoi tu parles.
Facebook utilise différents langages et fonction des besoins, et essai d'utiliser le plus adapté au service. Tu retrouves, entre autre, du:
- PHP pour les frontend
- Du C/C++ pour les caches, pour les serveurs de photos (cf. http://www.facebook.com/note.php?note_id=76191543919 ) ou pour la gestion des logs (voir scribe)
- Du Java pour tout ce qui touche au datawarehouse: Grosse contribution à hadoop, pig et hive, cassandra pour du map/reduce, bigtable & co
- De l'Erlang pour le service de Chat
- Du Python (voir tornado)
D'ailleurs c'est pas un hasard si facebook à créé thrift qui permet la serialization et les appels RPC entre plusieurs langages !
Et certainement beaucoup d'autres choses qu'ils n'ont pas documentés.
Et pour le bozo qui t'as répondu, fourni un service qui tient la charge de fb et on en reparle après. Pour rappel, il y a quelques temps c'était 550.000 photos/sec servies en pic, 220 millions de nouvelles photos/semaine, 400 milliards de pages/mois.
Tu arrêtes de faire de la rhétorique à six sous des fois ?
Tout pays est régis par des lois. Elles peuvent être bonnes ou mauvaises, ce n'est pas le sujet. Ce n'est PAS le rôle d'une entreprise de déstabiliser un pouvoir en place, de faire de l'ingérence ou de violer sciemment une loi sur un critère arbitraire. Aussi critiquable soit il. Il n'y a heureusement que deux solutions, juger que les conditions sont inacceptables et ne pas t'implanter ou te soumettre aux autorités. Ce n'est pas à une entreprise de changer une loi ! Faut arrêter de déconner un peu !
Si on va par là, demain par ce que les américains jugent que nos conditions de travail sont trop strictes, tu vas encourager les multinationale à violer le droit Français ? Ou soutenir les compagnies pétrolière en Afrique...
> Sur quel critère juge ton qu'une loi doit être promulguée ou non ?
J'ai vraiment besoin de répondre, ou c'était juste pour le plaisir de t'entendre parler ?
> Loin de moi l'idee de dire que la censure en chine c'est cool, mais c'est pas un probleme de reseau la...
Non seulement ca n'a rien a voir avec la neutralité du réseau puisque c'est un service. Mais c'est surtout qu'on reproche à google de se plier au loi d'un pays !
Je ne vois personne critiquer google lorsqu'ils se plient aux lois francaises qui imposent de filtrer certains résultats (propagande nazi par exemple). On peut discuter du bien fondé des lois francaises ou chinoises. Mais il ne me semble pas opportun de demander à une entreprise de violer les règles des pays où elle offre son service. Sur quel critère juge ton qu'une loi doivent être violée ou non ?
Il n'y a que deux solutions, ne pas offrir ses services dans un état donné ou se plier aux lois locales. Économiquement parlant, se couper de la chine c'est du suicide...
Bien entendu je soutiens en rien les pratiques de la chine. Mais pour moi tapper sur google, c'est taper sur la mauvaise personne.
Finding new ways to improve PHP performance isn't a new concept. At run time the Zend Engine turns your PHP source into opcodes which are then run through the Zend Virtual Machine. Open source projects such as APC and eAccelerator cache this output and are used by the majority of PHP powered websites. There's also Zend Server, a commercial product which makes PHP faster via opcode optimization and caching. Instead, we were thinking about transforming PHP source directly into C++ which can then be turned into native machine code. Even compiling PHP isn't a new idea, open source projects like Roadsend and phc compile PHP to C, Quercus compiles PHP to Java, and Phalanger compiles PHP to .Net.
Needless to say, it took longer than that single Hackathon. Eight months later, I had enough code to demonstrate it is indeed possible to run faster with compiled code. We quickly added Iain Proctor and Minghui Yang to the team to speed up the pace of the project. We spent the next ten months finishing up all the coding and the following six months testing on production servers. We are proud to say that at this point, we are serving over 90% of our Web traffic using HipHop, all only six months after deployment.
Tu penses sincèrement que les mecs ont passé un an à développer leur truc et à le mettre en prod sans avoir évalué les solutions déjà existantes ? Vous prenez vraiment tout le monde pour des abrutis ou quoi ?
> Si c'est pour gagner 50%, c'est vraiment pas optimisé... pas plus qu'un cache-op.
Par ce que tu as benchmarké un cache op sur leur prod ? T'as pas l'impression de comparer des choux et des carottes ?
Le prend pas personnellement mais ça me fera toujours marrer les discutions de comptoir qui expliquent aux teams engineering des plus gros site web du monde comment il faudrait faire pour que leur site marche mieux (et qu'ils sont vraiment trop cons)...
> Donc je ne suis pas convaincu pour le gain en vitesse. D'autant plus que l'on parle d'un gain de performance sur la partie qui peut être facilement dupliquée, il suffit de créer un serveur clone du premier et de repartir la charge entre les deux et c'est bon (enfin presque ;)
Ils annoncent une réduction de la charge de 50% sur leur frontend en prod. Tu veux faire le calcul du pognon gagné quand tu as un datacenter de cette taille ? Autrement dupliquer bêtement ça n'a jamais marché tout seul, et surtout pas à cette échelle... Je pense même qu'ils sont déjà un peu au courant.
> Maintenant ce genre de compilation de code risque de provoquer des incompatibilités et des problématiques de maintenance tordue. Je ne suis pas près à sacrifier la maintenabilité et la simplicité de développement pour un millième de seconde gagné à chaque requête.
Sur 10 milliards de pages vues par jour ça peut commencer à se défendre de gagner un millième de seconde. C'est une bête histoire de coût de dev VS coût opérationnel.
Après pour toi et ton site web, personne n'a dit que ça sera utile. Mais dire que leur outil ne sert à rien, j'attendrais d'avoir un peu plus de recul et de données en main...
Effectivement il y a beaucoup d'alternatives possibles. Il faut évaluer la pertinence de chacune en fonction de ses besoins.
Tu as raison, pour faire un serveur web avec netty/mina/grizzly il faut avoir une bonne raison puisque ça implique de réimplemanter HTTP soit même (ou tout du moins la partie dont on a besoin). Asyncweb fait ce sale boulot en se basant sur mina pour fournir un outil adapté à cette problématique particulière.
Au moins ce journal montre qu'en dehors des usines à gaz J2EE, il existe de très très bon projets qui simplifient vraiment la vie des développeurs.
Netty et Jetty ne jouent pas du tout sur le même terrain:
- Netty c'est un framework pour développer des clients/serveurs réseaux à base d'I/O asynchrone.
- Jetty c'est un container de servlet et un serveur HTTP.
L'un te propose le paradigme servlet, et donc abstrait le protocole réseau, ne te donne aucun contrôle dessus, et te fournit des I/O synchrone. L'autre te propose de quoi développer ton propre protocole réseau et ne te fournis qu'un framework événementiel d'I/O asynchrone très bien foutu et rien au dessus.
Pour faire simple; si tu as besoin de développer un site web classique avec des servlets et tout, tu vas te diriger vers Jetty.
Si tu as besoin de fournir un service très particulier, tu repars du sol avec Netty. Ca peut être pour implémenter ton propre protocole ou par ce que ton cas d'utilisation est très particulier. Par exemple si tu veux fournir un service de vidéo en HTTP, Jetty n'est pas adapté et il vaut mieux construire ton propre serveur web.
Cela dit les deux ont en commun leur très grande qualité technique, une prise en main facile et une bonne documentation. Très agréable de travailler avec ces deux là !
Tu compares deux choses différentes. D'un côté les serveurs HTTP/containers de servlet et de l'autre les serveurs d'application J2EE. Les seconds reposent sur les premiers et fournissent bien plus de fonctionnalités. Jetty se compare à tomcat. On peut le retrouver comme base de serveurs d'application tels que Geronimo, JBoss ou Jonas.
Après je te suis totalement sur le fait que Jetty est super bien foutu et mérite son succès. Un plaisir à utiliser et lire son code. Ce n'est pas un hasard si énormément de projets ayant besoin de fournir un serveur HTTP l'embarquent ! C'est bien conçu, c'est fiable, tout est configurable et c'est léger.
Je passe sur l'attaque du début, bien que le terme Parisien me fasse bien marrer.
Ça ne te pose aucun problème que quand tu recherches un arrêt dans la commune Beausoleil, il te propose la bonne commune (06240) où aucun gare n'existe et te donne un trajet pour aller à l'arrêt de bus beausoleil de Masseret (19510) qui se situe à 850km la commune indiquée ? Pire encore c'est sur le site ter PACA, pas voyage sncf !
Moi quand on me confirme explicitement que j'ai demandé un trajet entre 06000 et 06240 je m'attends à ce que mon propose le bon trajet, qu'on me dise que ca n'existe pas, voir qu'on me propose une solution approchante ! J'espère à ne jamais avoir à utiliser un de tes produits si tu trouves ca normal...
On notera que les code postaux sont les bons, et que donc pour faire 22km il nous propose: nice - lyon, lyon - bordeaux, bordeaux - limoge, limoge - masseret.
C'est clair qu'ils vont me faire préférer le train :p
Je crois tu as raté "entièrement libre" dans ma phrase. Qui soulignait que l'assertion du message précédent me semblait assez présomptueuse (des pros avec des workflow entièrement libre).
Ton article souligne justement ce que je dis ! Et on utilise plus ou moins les mêmes outils ;)
> je me dis que plus que les fonctionnalités, c'est l'habitude qui est difficile à changer, c'est l'habitude également qui fait qu'on arrive à être efficace
D'une part les solutions libres manquent actuellement de fonctionnalités.
D'autre part tout les logiciels ont une courbe d'apprentissage. La question c'est une fois que je me suis fait chier à apprendre ce logiciel est ce que je suis productif ? La réponse est encore majoritairement non...
> Comme je l'ai dit, je ne suis pas un pro de la photo (loin de là) du coup je n'ai pas les problématiques sur l'efficacité
Ca n'a rien a voir avec être un pro. C'est une question d'aimer perdre son temps ou non, et d'arriver ou pas à faire ce que l'on veut.
> scriptable pour automatiser les développements des fichiers raw.
Sauf que le tirage d'un raw c'est une étape entièrement basée sur ce que tu vois à l'écran... À chaque fois que change un paramètre tu regardes le rendu et tu adaptes.
Ensuite ce qu'on demande au logiciel c'est de pouvoir facilement propager un ensemble de réglages à certaines images en fonction de critères précis, et de permettre les exports par lots. La prévisualisation doit être instantanée, ce n'est pas acceptable d'attendre 10 secondes à chaque fois que tu changes un paramètre.
Si tu arrives à faire tout ça, très rapidement , sans attendre et sans utiliser ou presque la souris alors tu as un logiciel efficace....
Faire ca en ligne de commande à coup de script relève juste du cauchemar et de l'improductivité la plus totale pour pallier ce que devrait faire le logiciel.Si ça te plait c'est ton choix mais je doute que tu trouves des petits camarades. La ligne de commande c'est très bien pour redimensionner automatiquement un ensemble de photos ou appliquer un unsharp mask sur toutes les photos publiés. Pour tirer un raw, non !
Je traine sur virus photo et ailleurs de temps en temps et c'est pour ça que je te demande si tu as une référence précise.
Dans la liste que tu donnes, on voit justement qu'il y a un gros trou pour le développement des raw, qui reste la pièce maitresse d'un workflow et souvent on utilise le même logiciel pour développer les raw et gérer la bibliothèque. On ne sort du logiciel que pour retoucher les TIFF (gimp/photoshop) et les traitements spéciaux type HDR ou panoramiques.
Y'a certainement quelques personnes qui utilisent blue marine ou ufraw, mais ca me semble plus être un choix philosophique que pragmatique. Et quand tu as quelques Go de données à trier chaque jour, que ton salaire dépend de la qualité de tes tirages, et que ton temps n'est pas illimité le choix est vite fait... En temps que simple amateur, ça me gave de lutter pour tirer mes photos et pour le moment je préfère largement lâcher 100$ à Bibble pour gagner quelques heures à chaque sortie photo et garder du plaisir une fois que la CF est vidée...
Je suis utilisateur de bibble, j'ai testé lightroom (mais j'ai pas de Windows donc ca l'excluait d'office) et pour le moment Raw Therapee me semble très loin d'être au niveau. J'ai testé sur une sortie ce we, il y a des bugs flagrants, l'ergonomie n'est pas la du tout, y'a pas de plugin, et je trouve le rendu moins propre.
Bref c'est une très bonne nouvelle à long terme si la sauce prend. Mais actuellement, ca me semble difficilement un bon choix d'un point de vue photographe.
Ca fait bien 6 ans que j'ai pas écrit une ligne de C mais si je me souviens bien de la spec C99 un objet qui possède une "static storage duration" est initialisé à 0/NULL.. Ici on a des objets qui sont en "external linkage". Donc si j'ai pas tout oublié je vois pas en quoi c'est douteux.
Ce sont les objets en "automatic storage duration" qui ne sont pas initialisés.
Je ne suis pas développeur gnome mais ne dirais tu pas un peu n'importe quoi à propos de GConf ? Les fichiers de configurations sont trivialement simples et il est très facile de comprendre comment cela marche et de les éditer à la main.
Je ne savais pas comment ca marchait il y a dix minutes. Mais en utilisant son cerveau, ce n'est pas très difficile à faire soit même.
1- Ouvrir le schema de l'application. Ici ça sera /etc/gconf/schemas/desktop_gnome_background.schemas
2- Identifier la clé à configurer dans ce fichier. On trouve facilement, le nom de la clé, le type de valeur, la valeur par défaut et la documentation.
3- Ouvrir le fichier de configuration: ~/.gconf/desktop/gnome/background/%gconf.xml
4- Ajouter ou modifier la clé:
<entry name="picture_filename" mtime="1262709633" type="string">
<stringvalue>/tmp/1.jpg</stringvalue>
</entry>
C'est clair que c'est atrocement compliqué et totalement hors de portée... Tu peux nous proposer une solution fonctionnellement équivalente et beaucoup plus simple ? Si tu trouves tu pourras proposer un patch pour ajouter un nouveau backend !
Ce que tu critiques c'est une limitation actuelle de gconf qui n'a strictement rien avoir avec les fichiers de configuration. Gconf est un serveur de configuration qui offre une API pour configurer et consulter les valeurs et de les stocker de manière pérenne en utilisant un backend. Par défaut le backend XML est utilisé. Le démon tourne en permanence, il doit être utiliser pour consulter la valeur d'une clé et peut être utilisé pour la configurer. Il s'occupe aussi de notifier les applications quand une clé change. Comme ils font bien les choses chez gnome, voir http://library.gnome.org/devel/gconf/stable/gconf-gconf-backend.html , il est prévu qu'un backend puisse notifier qu'une valeur a été changé sans passer par l'API ( ce qui correspond dans notre cas à une édition manuelle du fichier XML). Actuellement le backend XML n'implémente pas cette fonctionnalité, cf NULL, /* set_notify_func */ ligne 231 dans xml-backend.c
On peut très facilement imaginer pourquoi c'est difficile à implémenter: gestion des conflits, réconciliation, état incohérents etc. Si le sujet t'intéresse, tu peux proposer un patch je pense.
Alors tu peux très bien faire la manip à la main, mais actuellement il faut que tu arrêtes ton démon gconf, que tu édites le fichier et que tu redémarre le démon.
Si un dev gnome veut me corriger il est le bienvenu ! Certains ont la critique et le préjugé facile je trouve...
Je ne peux que te suivre. En effet les espaces significatifs dans le genre idée à la con c'est pas mal (copie coller un fichier de config en YAML sur linuxfr qui bouffe les espaces qu'on rigole coup).
Tu perds toute notion de schema et de documents valides. Du coup comment j'ai la complétion sur mes fichiers de config ou la documentation interactive directement dans mon éditeur ?
Plus accessoire, tu dis adieu à tout les outils & toutes les transfos automatiques
Non c'est sur ca n'a que des avantages pour gagner 100 caractères :-) Et pourtant je milite pour une utilisation raisonnée du XML...
C'est vrai que c'était mieux avant !
- Devoir configurer son éditeur de texte en lisp
- Ou en python par ce que maintenant c'est la mode
- Son MTA à coup de macro m4
- Le logiciel que tu veux avec une syntaxe merdique qui fait saigner tes yeux
- Ajoute ton exemple ici, y'en a plein
- Tiens on pourrait parler d'apache aussi !
Alors oui il y a de plus en plus de dev qui vont à la facilité, et dans certain cas on pourrait utiliser quelque chose de plus léger . Mais j'ai plus l'impression que certains font une réaction allergique par principe ou simplement par ce qu'ils ne veulent pas prendre 10 minutes pour se former. C'est peut être un peu plus verbeux, mais en utilisant les outils adéquats il a aussi des avantages, tant pour le développeur que pour l'utilisateur:
- Savoir si son fichier de conf est valide en direct à l'édition
- Auto documentation
- Complétion automatique
- Réutilisation des connaissances et des outils. Pas besoin d'apprendre 12 syntaxes différentes
- En utilisant un outil adéquat, c'est pas tes petits doigts boudinés qui tapent le côté verbeux
Honnêtement tu prends le problème à l'envers. Si tu regardes le terme que j'ai employé, tu verras que je suis un peu du même avis que toi. Et soit dit au passage je mettrais pas xiti ou mediametrie dans le même panier que wikio...
Maintenant il faut pas se voiler la face, pour allez parler de partenariat ou négocier un contrat de pub en France tu as besoin d'un presta reconnu par le client (= médiamétrie pour un marché Francais). Que ca te plaise ou non.
[^] # Re: Google
Posté par ckyl . En réponse au journal J'aime pas... Google. Évalué à 1.
Mais au passage tu as complétement changé les specs de ce qu'il veut faire. Tu es passé d'un serveur web offrant les applications courantes déjà intégrées à un système de backup... Il n'y a pas de secret, si tu veux qu'un serveur web à l'autre bout de la planète serve tes données, alors il faut qu'il puisse les lire. Tu peux oublier tout le pan sécurité, chiffrement etc. Et ca ne s'appelle plus du HTTP/nav puisque il va falloir localiser les données (sauf gros hack dégueulasse avec service de localisation centralisé, HTTP redirect & co).
[^] # Re: Mouais
Posté par ckyl . En réponse au journal J'aime pas... Google. Évalué à 10.
- Soit les gens ne voient pas le problème que google utilise des documents dont les propriétaires ont donné leur permission pour une telle exploitation, et ont renseigné les géotag
- Soit les gens ne voient pas le problème que google fasse ce que flickr et tout les plateforme de publication de photo offrent depuis des années... Visualiser les photo géotagées sur une carte !
Sur ce coup la google ne fait rien de mal semble t-il. Ils exploitent les données que les services tierces et les propriétaires des documents ont bien voulu laisser exploitables (API publique, documents sous CC & co). Si tu mets des documents librement accessibles et utilisables, il ne faut pas venir se plaindre que quelqu'un les utilise...
[^] # Re: Targeted Advertising Cookie Opt-Out c'est assez naïf
Posté par ckyl . En réponse au journal Surfer sans traces selon Riseup. Évalué à 2.
Reste juste à virer à la main une fois les cookies flashs (LSO) et ça marche plutôt bien. Juste penser à ne pas cocher le partage d'info puisque ghostery a été revendu à better advertising.
[^] # Re: Ca me fait doucement rire ....
Posté par ckyl . En réponse au journal Terracotta monte les JVM en grappe. Évalué à 10.
Ebay c'est du Java (Ils utilisent que la partie "basse" de J2EE), Amazon c'est majoritairement du Java (Certains traitement sont en C++ ou Perl), linked-in c'est du Java (sauf la gestion du graphe), certains service yahoo c'est du java, orbitz aussi. Non vraiment y'a rien a dire Java ca marchera jamais, c'est pas efficace et y'a pas plus couteux en prod. Tout les gros s'en sont d'ailleurs aperçu, et ne contribuent absolument pas aux projets de la fondation Apache ;-)
C'est pas par ce que les SSII pondent des bouzes infâmes que Java c'est de la merde. C'est juste par ce qu'ils pondent des bouzes...
[^] # Re: Ca me fait doucement rire ....
Posté par ckyl . En réponse au journal Terracotta monte les JVM en grappe. Évalué à 6.
Facebook utilise différents langages et fonction des besoins, et essai d'utiliser le plus adapté au service. Tu retrouves, entre autre, du:
- PHP pour les frontend
- Du C/C++ pour les caches, pour les serveurs de photos (cf. http://www.facebook.com/note.php?note_id=76191543919 ) ou pour la gestion des logs (voir scribe)
- Du Java pour tout ce qui touche au datawarehouse: Grosse contribution à hadoop, pig et hive, cassandra pour du map/reduce, bigtable & co
- De l'Erlang pour le service de Chat
- Du Python (voir tornado)
D'ailleurs c'est pas un hasard si facebook à créé thrift qui permet la serialization et les appels RPC entre plusieurs langages !
Et certainement beaucoup d'autres choses qu'ils n'ont pas documentés.
Et pour le bozo qui t'as répondu, fourni un service qui tient la charge de fb et on en reparle après. Pour rappel, il y a quelques temps c'était 550.000 photos/sec servies en pic, 220 millions de nouvelles photos/semaine, 400 milliards de pages/mois.
[^] # Re: Google va avoir des problèmes avec le monde du libre
Posté par ckyl . En réponse au journal Android éjecté du noyau: l'avis de Greg Kroah-Hartman. Évalué à 9.
Tout pays est régis par des lois. Elles peuvent être bonnes ou mauvaises, ce n'est pas le sujet. Ce n'est PAS le rôle d'une entreprise de déstabiliser un pouvoir en place, de faire de l'ingérence ou de violer sciemment une loi sur un critère arbitraire. Aussi critiquable soit il. Il n'y a heureusement que deux solutions, juger que les conditions sont inacceptables et ne pas t'implanter ou te soumettre aux autorités. Ce n'est pas à une entreprise de changer une loi ! Faut arrêter de déconner un peu !
Si on va par là, demain par ce que les américains jugent que nos conditions de travail sont trop strictes, tu vas encourager les multinationale à violer le droit Français ? Ou soutenir les compagnies pétrolière en Afrique...
> Sur quel critère juge ton qu'une loi doit être promulguée ou non ?
J'ai vraiment besoin de répondre, ou c'était juste pour le plaisir de t'entendre parler ?
[^] # Re: Google va avoir des problèmes avec le monde du libre
Posté par ckyl . En réponse au journal Android éjecté du noyau: l'avis de Greg Kroah-Hartman. Évalué à 9.
Non seulement ca n'a rien a voir avec la neutralité du réseau puisque c'est un service. Mais c'est surtout qu'on reproche à google de se plier au loi d'un pays !
Je ne vois personne critiquer google lorsqu'ils se plient aux lois francaises qui imposent de filtrer certains résultats (propagande nazi par exemple). On peut discuter du bien fondé des lois francaises ou chinoises. Mais il ne me semble pas opportun de demander à une entreprise de violer les règles des pays où elle offre son service. Sur quel critère juge ton qu'une loi doivent être violée ou non ?
Il n'y a que deux solutions, ne pas offrir ses services dans un état donné ou se plier aux lois locales. Économiquement parlant, se couper de la chine c'est du suicide...
Bien entendu je soutiens en rien les pratiques de la chine. Mais pour moi tapper sur google, c'est taper sur la mauvaise personne.
[^] # Re: blitzen
Posté par ckyl . En réponse au journal HipHop For PHP : Facebook php-to-C++ translator. Évalué à 10.
Finding new ways to improve PHP performance isn't a new concept. At run time the Zend Engine turns your PHP source into opcodes which are then run through the Zend Virtual Machine. Open source projects such as APC and eAccelerator cache this output and are used by the majority of PHP powered websites. There's also Zend Server, a commercial product which makes PHP faster via opcode optimization and caching. Instead, we were thinking about transforming PHP source directly into C++ which can then be turned into native machine code. Even compiling PHP isn't a new idea, open source projects like Roadsend and phc compile PHP to C, Quercus compiles PHP to Java, and Phalanger compiles PHP to .Net.
Needless to say, it took longer than that single Hackathon. Eight months later, I had enough code to demonstrate it is indeed possible to run faster with compiled code. We quickly added Iain Proctor and Minghui Yang to the team to speed up the pace of the project. We spent the next ten months finishing up all the coding and the following six months testing on production servers. We are proud to say that at this point, we are serving over 90% of our Web traffic using HipHop, all only six months after deployment.
Tu penses sincèrement que les mecs ont passé un an à développer leur truc et à le mettre en prod sans avoir évalué les solutions déjà existantes ? Vous prenez vraiment tout le monde pour des abrutis ou quoi ?
> Si c'est pour gagner 50%, c'est vraiment pas optimisé... pas plus qu'un cache-op.
Par ce que tu as benchmarké un cache op sur leur prod ? T'as pas l'impression de comparer des choux et des carottes ?
[^] # Re: Pas convaincu
Posté par ckyl . En réponse au journal HipHop For PHP : Facebook php-to-C++ translator. Évalué à 10.
> Donc je ne suis pas convaincu pour le gain en vitesse. D'autant plus que l'on parle d'un gain de performance sur la partie qui peut être facilement dupliquée, il suffit de créer un serveur clone du premier et de repartir la charge entre les deux et c'est bon (enfin presque ;)
Ils annoncent une réduction de la charge de 50% sur leur frontend en prod. Tu veux faire le calcul du pognon gagné quand tu as un datacenter de cette taille ? Autrement dupliquer bêtement ça n'a jamais marché tout seul, et surtout pas à cette échelle... Je pense même qu'ils sont déjà un peu au courant.
> Maintenant ce genre de compilation de code risque de provoquer des incompatibilités et des problématiques de maintenance tordue. Je ne suis pas près à sacrifier la maintenabilité et la simplicité de développement pour un millième de seconde gagné à chaque requête.
Sur 10 milliards de pages vues par jour ça peut commencer à se défendre de gagner un millième de seconde. C'est une bête histoire de coût de dev VS coût opérationnel.
Après pour toi et ton site web, personne n'a dit que ça sera utile. Mais dire que leur outil ne sert à rien, j'attendrais d'avoir un peu plus de recul et de données en main...
[^] # Re: Netty
Posté par ckyl . En réponse au journal Jetty mais costaud. Évalué à 2.
Tu as raison, pour faire un serveur web avec netty/mina/grizzly il faut avoir une bonne raison puisque ça implique de réimplemanter HTTP soit même (ou tout du moins la partie dont on a besoin). Asyncweb fait ce sale boulot en se basant sur mina pour fournir un outil adapté à cette problématique particulière.
Au moins ce journal montre qu'en dehors des usines à gaz J2EE, il existe de très très bon projets qui simplifient vraiment la vie des développeurs.
[^] # Re: Netty
Posté par ckyl . En réponse au journal Jetty mais costaud. Évalué à 6.
- Netty c'est un framework pour développer des clients/serveurs réseaux à base d'I/O asynchrone.
- Jetty c'est un container de servlet et un serveur HTTP.
L'un te propose le paradigme servlet, et donc abstrait le protocole réseau, ne te donne aucun contrôle dessus, et te fournit des I/O synchrone. L'autre te propose de quoi développer ton propre protocole réseau et ne te fournis qu'un framework événementiel d'I/O asynchrone très bien foutu et rien au dessus.
Pour faire simple; si tu as besoin de développer un site web classique avec des servlets et tout, tu vas te diriger vers Jetty.
Si tu as besoin de fournir un service très particulier, tu repars du sol avec Netty. Ca peut être pour implémenter ton propre protocole ou par ce que ton cas d'utilisation est très particulier. Par exemple si tu veux fournir un service de vidéo en HTTP, Jetty n'est pas adapté et il vaut mieux construire ton propre serveur web.
Cela dit les deux ont en commun leur très grande qualité technique, une prise en main facile et une bonne documentation. Très agréable de travailler avec ces deux là !
# container de servlet VS serveur d'application
Posté par ckyl . En réponse au journal Jetty mais costaud. Évalué à 5.
Après je te suis totalement sur le fait que Jetty est super bien foutu et mérite son succès. Un plaisir à utiliser et lire son code. Ce n'est pas un hasard si énormément de projets ayant besoin de fournir un serveur HTTP l'embarquent ! C'est bien conçu, c'est fiable, tout est configurable et c'est léger.
[^] # Re: voyage-sncf
Posté par ckyl . En réponse au journal La SNCF confie son "informatique" à IBM. Évalué à 10.
Ça ne te pose aucun problème que quand tu recherches un arrêt dans la commune Beausoleil, il te propose la bonne commune (06240) où aucun gare n'existe et te donne un trajet pour aller à l'arrêt de bus beausoleil de Masseret (19510) qui se situe à 850km la commune indiquée ? Pire encore c'est sur le site ter PACA, pas voyage sncf !
Moi quand on me confirme explicitement que j'ai demandé un trajet entre 06000 et 06240 je m'attends à ce que mon propose le bon trajet, qu'on me dise que ca n'existe pas, voir qu'on me propose une solution approchante ! J'espère à ne jamais avoir à utiliser un de tes produits si tu trouves ca normal...
[^] # Re: voyage-sncf
Posté par ckyl . En réponse au journal La SNCF confie son "informatique" à IBM. Évalué à 10.
http://img709.imageshack.us/img709/5752/sncf.png
On notera que les code postaux sont les bons, et que donc pour faire 22km il nous propose: nice - lyon, lyon - bordeaux, bordeaux - limoge, limoge - masseret.
C'est clair qu'ils vont me faire préférer le train :p
[^] # Re: Et sinon
Posté par ckyl . En réponse au journal Photographie et Linux enfin réconciliés. Évalué à 3.
Ton article souligne justement ce que je dis ! Et on utilise plus ou moins les mêmes outils ;)
[^] # Re: Une question d'habitude ?
Posté par ckyl . En réponse au journal Photographie et Linux enfin réconciliés. Évalué à 10.
D'une part les solutions libres manquent actuellement de fonctionnalités.
D'autre part tout les logiciels ont une courbe d'apprentissage. La question c'est une fois que je me suis fait chier à apprendre ce logiciel est ce que je suis productif ? La réponse est encore majoritairement non...
> Comme je l'ai dit, je ne suis pas un pro de la photo (loin de là) du coup je n'ai pas les problématiques sur l'efficacité
Ca n'a rien a voir avec être un pro. C'est une question d'aimer perdre son temps ou non, et d'arriver ou pas à faire ce que l'on veut.
> scriptable pour automatiser les développements des fichiers raw.
Sauf que le tirage d'un raw c'est une étape entièrement basée sur ce que tu vois à l'écran... À chaque fois que change un paramètre tu regardes le rendu et tu adaptes.
Ensuite ce qu'on demande au logiciel c'est de pouvoir facilement propager un ensemble de réglages à certaines images en fonction de critères précis, et de permettre les exports par lots. La prévisualisation doit être instantanée, ce n'est pas acceptable d'attendre 10 secondes à chaque fois que tu changes un paramètre.
Si tu arrives à faire tout ça, très rapidement , sans attendre et sans utiliser ou presque la souris alors tu as un logiciel efficace....
Faire ca en ligne de commande à coup de script relève juste du cauchemar et de l'improductivité la plus totale pour pallier ce que devrait faire le logiciel.Si ça te plait c'est ton choix mais je doute que tu trouves des petits camarades. La ligne de commande c'est très bien pour redimensionner automatiquement un ensemble de photos ou appliquer un unsharp mask sur toutes les photos publiés. Pour tirer un raw, non !
[^] # Re: Et sinon
Posté par ckyl . En réponse au journal Photographie et Linux enfin réconciliés. Évalué à 2.
Dans la liste que tu donnes, on voit justement qu'il y a un gros trou pour le développement des raw, qui reste la pièce maitresse d'un workflow et souvent on utilise le même logiciel pour développer les raw et gérer la bibliothèque. On ne sort du logiciel que pour retoucher les TIFF (gimp/photoshop) et les traitements spéciaux type HDR ou panoramiques.
Y'a certainement quelques personnes qui utilisent blue marine ou ufraw, mais ca me semble plus être un choix philosophique que pragmatique. Et quand tu as quelques Go de données à trier chaque jour, que ton salaire dépend de la qualité de tes tirages, et que ton temps n'est pas illimité le choix est vite fait... En temps que simple amateur, ça me gave de lutter pour tirer mes photos et pour le moment je préfère largement lâcher 100$ à Bibble pour gagner quelques heures à chaque sortie photo et garder du plaisir une fois que la CF est vidée...
[^] # Re: Et sinon
Posté par ckyl . En réponse au journal Photographie et Linux enfin réconciliés. Évalué à 6.
Hum je serais intéressé par voir un workflow entièrement libre et efficace... Tu peux me filer des références ?
[^] # Re: En parlant de concurrence
Posté par ckyl . En réponse à la dépêche RawTherapee, logiciel de retouche photo, sort en GPL !. Évalué à 2.
Je suis utilisateur de bibble, j'ai testé lightroom (mais j'ai pas de Windows donc ca l'excluait d'office) et pour le moment Raw Therapee me semble très loin d'être au niveau. J'ai testé sur une sortie ce we, il y a des bugs flagrants, l'ergonomie n'est pas la du tout, y'a pas de plugin, et je trouve le rendu moins propre.
Bref c'est une très bonne nouvelle à long terme si la sauce prend. Mais actuellement, ca me semble difficilement un bon choix d'un point de vue photographe.
[^] # Re: Et après ?
Posté par ckyl . En réponse à la dépêche Fabrice Bellard bat le record des décimales de Pi. Évalué à 5.
Ce sont les objets en "automatic storage duration" qui ne sont pas initialisés.
[^] # Re: script
Posté par ckyl . En réponse au journal Requête aux devs de logiciels libres. Évalué à 2.
Je ne savais pas comment ca marchait il y a dix minutes. Mais en utilisant son cerveau, ce n'est pas très difficile à faire soit même.
1- Ouvrir le schema de l'application. Ici ça sera /etc/gconf/schemas/desktop_gnome_background.schemas
2- Identifier la clé à configurer dans ce fichier. On trouve facilement, le nom de la clé, le type de valeur, la valeur par défaut et la documentation.
3- Ouvrir le fichier de configuration: ~/.gconf/desktop/gnome/background/%gconf.xml
4- Ajouter ou modifier la clé:
<entry name="picture_filename" mtime="1262709633" type="string">
<stringvalue>/tmp/1.jpg</stringvalue>
</entry>
C'est clair que c'est atrocement compliqué et totalement hors de portée... Tu peux nous proposer une solution fonctionnellement équivalente et beaucoup plus simple ? Si tu trouves tu pourras proposer un patch pour ajouter un nouveau backend !
Ce que tu critiques c'est une limitation actuelle de gconf qui n'a strictement rien avoir avec les fichiers de configuration. Gconf est un serveur de configuration qui offre une API pour configurer et consulter les valeurs et de les stocker de manière pérenne en utilisant un backend. Par défaut le backend XML est utilisé. Le démon tourne en permanence, il doit être utiliser pour consulter la valeur d'une clé et peut être utilisé pour la configurer. Il s'occupe aussi de notifier les applications quand une clé change. Comme ils font bien les choses chez gnome, voir http://library.gnome.org/devel/gconf/stable/gconf-gconf-backend.html , il est prévu qu'un backend puisse notifier qu'une valeur a été changé sans passer par l'API ( ce qui correspond dans notre cas à une édition manuelle du fichier XML). Actuellement le backend XML n'implémente pas cette fonctionnalité, cf NULL, /* set_notify_func */ ligne 231 dans xml-backend.c
On peut très facilement imaginer pourquoi c'est difficile à implémenter: gestion des conflits, réconciliation, état incohérents etc. Si le sujet t'intéresse, tu peux proposer un patch je pense.
Alors tu peux très bien faire la manip à la main, mais actuellement il faut que tu arrêtes ton démon gconf, que tu édites le fichier et que tu redémarre le démon.
Si un dev gnome veut me corriger il est le bienvenu ! Certains ont la critique et le préjugé facile je trouve...
[^] # Re: Vous devez entrer un sujet et un commentaire
Posté par ckyl . En réponse au journal Requête aux devs de logiciels libres. Évalué à 4.
Tu peux reprendre l'exemple du META.yml utilisé ici: https://linuxfr.org//comments/1054702.html#1054702
[^] # Re: Vous devez entrer un sujet et un commentaire
Posté par ckyl . En réponse au journal Requête aux devs de logiciels libres. Évalué à 10.
C'est pas beaucoup plus court ni plus lisible (cf. une veille discussion https://linuxfr.org//comments/1054702.html#1054702 ).
Tu perds toute notion de schema et de documents valides. Du coup comment j'ai la complétion sur mes fichiers de config ou la documentation interactive directement dans mon éditeur ?
Plus accessoire, tu dis adieu à tout les outils & toutes les transfos automatiques
Non c'est sur ca n'a que des avantages pour gagner 100 caractères :-) Et pourtant je milite pour une utilisation raisonnée du XML...
# Poutre paille....
Posté par ckyl . En réponse au journal Requête aux devs de logiciels libres. Évalué à 9.
- Devoir configurer son éditeur de texte en lisp
- Ou en python par ce que maintenant c'est la mode
- Son MTA à coup de macro m4
- Le logiciel que tu veux avec une syntaxe merdique qui fait saigner tes yeux
- Ajoute ton exemple ici, y'en a plein
- Tiens on pourrait parler d'apache aussi !
Alors oui il y a de plus en plus de dev qui vont à la facilité, et dans certain cas on pourrait utiliser quelque chose de plus léger . Mais j'ai plus l'impression que certains font une réaction allergique par principe ou simplement par ce qu'ils ne veulent pas prendre 10 minutes pour se former. C'est peut être un peu plus verbeux, mais en utilisant les outils adéquats il a aussi des avantages, tant pour le développeur que pour l'utilisateur:
- Savoir si son fichier de conf est valide en direct à l'édition
- Auto documentation
- Complétion automatique
- Réutilisation des connaissances et des outils. Pas besoin d'apprendre 12 syntaxes différentes
- En utilisant un outil adéquat, c'est pas tes petits doigts boudinés qui tapent le côté verbeux
Y'a du pour et du contre...
[^] # Re: Commercial et vie privée.
Posté par ckyl . En réponse au journal Personas, l'extension de personnalisation graphique de Firefox. Évalué à 2.
Maintenant il faut pas se voiler la face, pour allez parler de partenariat ou négocier un contrat de pub en France tu as besoin d'un presta reconnu par le client (= médiamétrie pour un marché Francais). Que ca te plaise ou non.