Vu les mouchard qui trainent dans certaines apps (pub, analytics, profiling) c'est quand meme une bonne chose.
Et on peut aussi faire du mauvais esprit, ca serait finalement pour proteger iAd de la concurrence…
Je suis prêt à payer 60 euro pour 3 saisons d'une série en VOD, si j'ai accès aux épisodes le jour où elle sort aux USA avec les voix anglaises et les sous-titres français (ce qu'on a actuellement avec bittorrent*). Ah et je veux pouvoir visionner la série avec le lecteur vidéo que je choisis, pas une merde en flash qui plante une fois sur deux (donc soit téléchargement soit un protocole que VLC/mplayer comprend).
Ca depend si c'est un probleme de code ou un probleme de design. Prenons comme exemple recent apache avec les range request. C'est un probleme de design par un simple bug problematique.
D'autre part, ceux qui sont dans les secret d'alcove pourront confirmer, il n'est pas rare d'avoir une faille de securite reportee plusieurs semaines/mois avant la publication d'un patch et le full disclosure. Generalement, l'annonce est faite a la hate si son exploitation devient massive. Bref, du FUD :)
C'est marrant. Quand on affirme que c'est de la merde et que ca ne fonctionne pas, nul besoin d'argument...
Une des differences principale entre le "c'est malin" et "c'est idiot" est le degres de confiance qu'on peut avoir dans l'intervenant. C'est du marketing.
Il n'y a guere plus de choix que de connaitre, etre convaincu ou etre septique.
Pour "prouver" (meme si a chaque probleme ses solutions) je vais essayer de prendre un sujet abordable.
Generallement, acheter du courant non ondule dans un DC et coller un onduleur perso en front est une idiotie. Mais, quand google colle une batterie on board sur ses serveurs, c'est un coup de genie.
Les exemples ne manquent pas : de danga a linkedin, du mouvement NoSQL au retour des
RDBMS, du C/C++ au Java pour des services critiques, du NFS au DFS userland.
Il faut tout simplement aller au dela du delit de sale geule, s'affranchir des discours hypnotiques pour juger de la pertinence d'une technologie a un probleme donne.
les considerations de l'auteur sont complementaires au contenu, on comprend mieux pourquoi l'auteur s'inquiete de la pression sur les developpeurs d'applications et craint des coups bas entre les differents editeurs/developpeurs.
Neanmoins, l'article est clair sur la position de twitter : "debrouillez vous pour masquer la clef" n'est pas la bonne solution.
Au dela, je ne connais pas OAuth et je ne peux me fier qu'a son discours qui me semble coherent et par consequent, a part regretter la postion de twitter je n'ai aucun avis.
Plus simple certes. mais est-ce que, pour ce type d'environnement elles sont adaptes ?
Les solutions auquelles tu fais allusions sont-elles multi-sites, fault tolerant, distribuees, a faible latence, economiques et idiot proof ?
Peux-tu me donner des solution infiniment plus simple a murder, hiphop, snowflake ou hive ?
Passee une certaine volumetrie, les pratiques "standards" ne sont plus adaptees, Les outils classiques peuvent montrer leurs limites. Avec le temps les infrastructures deviennent caduques, et il faut les revoir. Il existe des fausses bonnes idees, des concepts qui ne durent qu'un temps, des effets de mode.
Les trucs "hypes" ont au moins l'avantage de faire avancer les choses en bousculant les idees recues, ouvrant de nouvelles perspectives, decouvrant de nouvelles limites.
Utiliser des technos a la mode pour se faire mousser est generalement contre productif, les utiliser pour couvrir un besoin, innonver, assurer la monter la montee en charge ou tout simplement s'affranchir de contraintes applicatives est parfaitement sain. S'ecarter de l'orthodoxie n'est pas toujours une mauvaise chose.
parceque le memory fingerprint d'apache 2.2 est "gros" meme avec un MPM threade ?
apache httpd n'est plus le serveur web le plus rapide et moins gourmand :)
Mais apache 2.x a gagne en confort applicatif. Au boulot, on avait une douzaine de vieux clous avec apache 1.3.x compile en statique avec des patches et des modules maison.
Nous sommes passes a apache 2.2 avec event MPM.
Resultats des courses:
- Pas de patch pour le support SSL, mod_gzip ou IPv6
- plus qu'un patch sur les module d'apache d'origine (contre 12 avant)
- on chaine les modules + facilement
- pour le logging, plus besoin de se coltiner un patch pour mod_log_config
- on peut charger un lib apr-util sans avoir a se frapper une compilation
Et quand on passera a apache 2.4. on reduira encore le nombre de lignes de code maison.
Bref, c'est un bohneur d'ecrire un module apache :)
En revanche, le modele 1 threads/process = 1 connexion devient une plaie (d'ou l'interet de coller un haproxy devant).
Il y en a plusieurs. La principale est que le code a ete "segmente" pour faciliter la portablite et en rendre apache "en kit". D'ailleurs, l'ambition initiale de la branche 2.2 (puis 2.4 et finaliement 3.x) etait aussi de faire d'apache un meta-serveur.
Pour cela il y'a eu des changement important dans apache 2.x:
- apache depend de apr (Apache Portable Runtime) qui fourni une couche d'abstraction + les fonctions les plus communement utilisees. apr-util offre une collection d'API "wrappers" (libiconv, memcache, BDB, *SQL).
- La gestion des requetes est separee en 2 parties:
1. le MPM qui gere la connexion et "lance" la requete au sain du serveur.
2. les modules qui la traite (a noter qu'a la base, le traitement HTTP devait etre un module, mais ce dernier est encore trop lie au serveur)
Ce sont les changements les plus visible.
Au dela de ca, il y'a une meilleure gestion des hooks (pour l'execution des modules), le support des filtres (par ex pour la compression), le support de "pool" de connexion partages (apr_dbd), le support out of the box de SSL et IPv6 ;), une API flexible pour l'authentification, pour du cache et du proxying.
et pour apache 2.4 (pour le moment c'est 2.3.x) une API pour la gestion des sessions :)
et les mpm loadable (avant c'etait en dur)
[^] # Re: Problème de riches
Posté par sheldoncooper . En réponse au journal Viande ou pas viande ?. Évalué à 1.
C'est evident que la "nature" est la championne de la conservation des especes :-)
[^] # Re: Précisions
Posté par sheldoncooper . En réponse au journal Apple bannit les applications demandant le UUID. Évalué à 3.
Vu les mouchard qui trainent dans certaines apps (pub, analytics, profiling) c'est quand meme une bonne chose.
Et on peut aussi faire du mauvais esprit, ca serait finalement pour proteger iAd de la concurrence…
[^] # Re: C'est vendredi ?
Posté par sheldoncooper . En réponse au journal Mégaupload fermé, tant mieux ! Je suis comédien, mes films ne sont pas gratuits. Évalué à 2.
en france:
http://mytf1vod.tf1.fr/television/rattrapage-series-us/
[^] # Re: l'homéopathie
Posté par sheldoncooper . En réponse au journal Le violon et son contexte. Évalué à 6.
Allez juste pour le fun: http://www.pseudo-sciences.org/spip.php?article1604
[^] # Re: normal
Posté par sheldoncooper . En réponse au journal Microsoft et les virus, une longue histoire d'amour.. Évalué à 1.
Ca depend si c'est un probleme de code ou un probleme de design. Prenons comme exemple recent apache avec les range request. C'est un probleme de design par un simple bug problematique.
D'autre part, ceux qui sont dans les secret d'alcove pourront confirmer, il n'est pas rare d'avoir une faille de securite reportee plusieurs semaines/mois avant la publication d'un patch et le full disclosure. Generalement, l'annonce est faite a la hate si son exploitation devient massive. Bref, du FUD :)
[^] # Re: Ben merde alors, le MEDEF qui fait dans le social !
Posté par sheldoncooper . En réponse au journal Journée de la femme, droit des pères. Évalué à 2.
Assez repandu tout de meme: http://www.ameli.fr/fileadmin/user_upload/documents/Points_de_repere_n__20.pdf
Resume: 8 millions de patients ALD, en comptant plusieurs fois ceux qui en ont plusieurs (en moyenne 1.2 par patient)
[^] # Re: En tout cas ça a le mérite d'exister
Posté par sheldoncooper . En réponse au journal Diaspora mal conçu?. Évalué à 3.
Une des differences principale entre le "c'est malin" et "c'est idiot" est le degres de confiance qu'on peut avoir dans l'intervenant. C'est du marketing.
Il n'y a guere plus de choix que de connaitre, etre convaincu ou etre septique.
Pour "prouver" (meme si a chaque probleme ses solutions) je vais essayer de prendre un sujet abordable.
Generallement, acheter du courant non ondule dans un DC et coller un onduleur perso en front est une idiotie. Mais, quand google colle une batterie on board sur ses serveurs, c'est un coup de genie.
Les exemples ne manquent pas : de danga a linkedin, du mouvement NoSQL au retour des
RDBMS, du C/C++ au Java pour des services critiques, du NFS au DFS userland.
Il faut tout simplement aller au dela du delit de sale geule, s'affranchir des discours hypnotiques pour juger de la pertinence d'une technologie a un probleme donne.
[^] # Re: En tout cas ça a le mérite d'exister
Posté par sheldoncooper . En réponse au journal Diaspora mal conçu?. Évalué à 2.
Neanmoins, l'article est clair sur la position de twitter : "debrouillez vous pour masquer la clef" n'est pas la bonne solution.
Au dela, je ne connais pas OAuth et je ne peux me fier qu'a son discours qui me semble coherent et par consequent, a part regretter la postion de twitter je n'ai aucun avis.
[^] # Re: En tout cas ça a le mérite d'exister
Posté par sheldoncooper . En réponse au journal Diaspora mal conçu?. Évalué à 2.
Les solutions auquelles tu fais allusions sont-elles multi-sites, fault tolerant, distribuees, a faible latence, economiques et idiot proof ?
Peux-tu me donner des solution infiniment plus simple a murder, hiphop, snowflake ou hive ?
Passee une certaine volumetrie, les pratiques "standards" ne sont plus adaptees, Les outils classiques peuvent montrer leurs limites. Avec le temps les infrastructures deviennent caduques, et il faut les revoir. Il existe des fausses bonnes idees, des concepts qui ne durent qu'un temps, des effets de mode.
Les trucs "hypes" ont au moins l'avantage de faire avancer les choses en bousculant les idees recues, ouvrant de nouvelles perspectives, decouvrant de nouvelles limites.
Utiliser des technos a la mode pour se faire mousser est generalement contre productif, les utiliser pour couvrir un besoin, innonver, assurer la monter la montee en charge ou tout simplement s'affranchir de contraintes applicatives est parfaitement sain. S'ecarter de l'orthodoxie n'est pas toujours une mauvaise chose.
[^] # Re: En tout cas ça a le mérite d'exister
Posté par sheldoncooper . En réponse au journal Diaspora mal conçu?. Évalué à 2.
http://www.webupd8.org/2010/09/twitters-oauthpocalypse-today(...)
De plus il n'a pas l'air franchement conquis par OAuth:
http://omgsuse.com/content/meet-ryan-paul-creator-gwibber
[^] # Re: En tout cas ça a le mérite d'exister
Posté par sheldoncooper . En réponse au journal Diaspora mal conçu?. Évalué à 2.
pourquoi ?
[^] # Re: Petite erreur.
Posté par sheldoncooper . En réponse au journal 8 mars. Évalué à 1.
non ;)
c'est l'inverse justement. mais elle meurent moins jeune :)
http://tomroud.blogspot.com/2006/02/je-suis-un-survivant.htm(...)
[^] # Re: apache 1.3 et apache 2.2
Posté par sheldoncooper . En réponse au journal La fin du monde. Évalué à 1.
apache httpd n'est plus le serveur web le plus rapide et moins gourmand :)
Mais apache 2.x a gagne en confort applicatif. Au boulot, on avait une douzaine de vieux clous avec apache 1.3.x compile en statique avec des patches et des modules maison.
Nous sommes passes a apache 2.2 avec event MPM.
Resultats des courses:
- Pas de patch pour le support SSL, mod_gzip ou IPv6
- plus qu'un patch sur les module d'apache d'origine (contre 12 avant)
- on chaine les modules + facilement
- pour le logging, plus besoin de se coltiner un patch pour mod_log_config
- on peut charger un lib apr-util sans avoir a se frapper une compilation
Et quand on passera a apache 2.4. on reduira encore le nombre de lignes de code maison.
Bref, c'est un bohneur d'ecrire un module apache :)
En revanche, le modele 1 threads/process = 1 connexion devient une plaie (d'ou l'interet de coller un haproxy devant).
[^] # Re: apache 1.3 et apache 2.2
Posté par sheldoncooper . En réponse au journal La fin du monde. Évalué à 3.
Pour cela il y'a eu des changement important dans apache 2.x:
- apache depend de apr (Apache Portable Runtime) qui fourni une couche d'abstraction + les fonctions les plus communement utilisees. apr-util offre une collection d'API "wrappers" (libiconv, memcache, BDB, *SQL).
- La gestion des requetes est separee en 2 parties:
1. le MPM qui gere la connexion et "lance" la requete au sain du serveur.
2. les modules qui la traite (a noter qu'a la base, le traitement HTTP devait etre un module, mais ce dernier est encore trop lie au serveur)
Ce sont les changements les plus visible.
Au dela de ca, il y'a une meilleure gestion des hooks (pour l'execution des modules), le support des filtres (par ex pour la compression), le support de "pool" de connexion partages (apr_dbd), le support out of the box de SSL et IPv6 ;), une API flexible pour l'authentification, pour du cache et du proxying.
et pour apache 2.4 (pour le moment c'est 2.3.x) une API pour la gestion des sessions :)
et les mpm loadable (avant c'etait en dur)