Ils presentent ca comme un truc ouvert auquel tous les fabriquants de navigateurs sont invites a participer, mais bien evidemment que nous on n'a pas envie d'encourager le retour des plugins binaires
Il va falloir définir ouvert parce que je ne vois pas en quoi Native Client est fermé. Ok ils ont décidé d'une API tout seul, donc ce n'est pas un standard, mais à priori une énorme partie de Chrome est open source (Chromium) et il y a un site web pour les dev de navigateur intéressés à implémenter Native Client.
Ca n'a strictement rien à voir avec flash ou activex ou Adobe et Microsoft faisaient tout pour que personne d'autre ne puisse implémenter de plugin compatible.
Après, si vous pensez que Native Client n'est pas une bonne idée, libre à vous de ne pas l'implémenter et de proposer mieux. Mais ça ne veut strictement pas dire que Native Client est fermé.
Tu n'as pas l'air de porter python dans ton coeur, une raison à cela ?
Pourtant, pour avoir utilisé un peu sagemath et sympy pour du calcul formel (mais je suis informaticien, pas mathématicien), j'ai trouvé ça vraiment très intéressant et plutôt bien foutu. Etant écrit en python, c'est en plus facilement extensible et intégrable avec d'autres outils (matplotlib, numpy, scipy).
Y'a quand même pas mal de téléphones/tablets qui permettent d'installer facilement des ROMs alternatives. Au niveau téléphone, je pense que la série des Nexus de Google est le meilleur pari si on veut installer (ou faire soi-même) une ROM alternative.
Tu peux tout à fait aller télécharger les sources de cyanogenmod, les recompiler et installer ça. C'est clair qu'il faut des blobs binaires et c'est dommage, mais c'est la même chose pour pas mal d'ordinateurs qui tournent sous Linux (drivers wifi, graphiques), même si ça s'améliore.
Bref, on est d'accord qu'il faut mettre la pression pour que les fabriquants aillent vers des téléphones sans blobs binaires (comme il a fallu le faire avec les PC), mais de là à dire que Android c'est pas du tout libre, il y a un pas.
Je pense que l'hypothèse la plus vraisemblable est moins catastrophique : C'est un mélange entre le fait de vouloir faire quelque chose de technologique parce que la technologie c'est bien. C'est de l'innovation, toussa. L'autre aspect, c'est l'espoir que ça augmente la participation des jeunes qui pourront voter depuis leur iPhone. Comme ça, on pourra voter entre deux like facebook, ça va être supaire.
Il est un principe bien connu en sécurité qui dit que la sécurité d'une chaîne est égale à celle du maillon le plus faible.
Avec le vote par internet, on aura beau construire une chaîne super sécurisé entre l'état et le PC de l'utilisateur, le gros problème, celui qu'il sera vraiment très très très dur de résoudre, c'est la sécurité du PC de l'utilisateur. Si on est incapable de garantir la sécurité du PC de l'utilisateur, alors la jolie chaîne de sécurité qu'on a construite, elle est intéressante théoriquement, mais pratiquement ça ne vaut rien du tout.
Pour le JIT, oui je voulais dire Android. Enfin, Android 1.6 sur Magic n'a pas de JIT. Si je me souviens bien, le JIT est apparu avec la version 2.X, mais même en installant ça sur un Magic (cyanogenmod par exemple), le JIT est désactivé car le téléphone n'as pas assez de RAM.
Un petit retour pour que ça tourne sur un Magic :
- J'ai utilisé C++ plutôt que Java. Le Magic n'a pas de JIT (trop peu de mémoire) et Java est donc super lent sur ce téléphone qui n'est déjà pas rapide…
- Quitte à rester en Java, il vaut mieux éviter Canvas et Drawable et travailler directement en OpenGL. Ca permet d'être plus fin dans ce qu'on veut et on gagne des perfs.
- Y'a tout un tas de petit "tips" pour écrire du code Java performant sur Android. Ca passe par l'utilisation de static final lorsque c'est possible, éviter les getter, etc : http://developer.android.com/guide/practices/design/performance.html
- Mais si tu veux vraiment des bonnes perfs sur des téléphones bas de gamme, je crois que passer par C++ est nécessaire. C'est assez facile de faire du JNI sous Android. Pour mon jeu de tank, j'avais fais l'interface en Java et tout ce qui est jeu en C++.
Je me demande ceci dit à quel point l'attrait de HTTP vient de son mode texte. Le mode texte fait que pour un débutant, c'est facile à comprendre, on peut simplement lui montrer la requête.
Le mode texte fait que c'est aussi facile à implémenter dans la majorité des langages de prog (à coup de regexp ou de split, c'est super rapide à faire un parser HTTP). Si on compare ça à l'implémentation d'un parser pour Protobuf, ça fait une différence. Dès qu'on passe dans du binaire, on doit commencer à se poser des questions sur le décodage des entiers/float, etc… C'est pas la mort, mais on passe de "j'implémente un client en 30 minutes" à "je dois passer 2 jours à écrire mon parser".
Ceci dit, je suis un gros gros fan de Google Protobuf. J'utilise ça dans quasi tous mes projets à la place de JSON/XML, ça me permet d'avoir des messages typés avec un minimum de vérification et de cohérence.
Mais voilà, parfois, le texte c'est juste plus simple. Il faut aussi voir ce qu'on gagne en passant à du binaire. Si c'est pour garder la masse de headers inutiles, ça va pas changer grand chose.
Pour un exemple de protocol binaire est extensible tout en restant backward-compatible, tu peux jetter un oeil à Google Protocol Buffers par exemple : http://code.google.com/p/protobuf/
Ca a l'air un peu plus poussé que boostrap dans le sens où ça permet de donner des limites min/max à l'extension des div (d'où le nom flex).
Globalement, ça permet surtout de s'épargner les nombreux hack de boostrap et de faire des layouts un peu avancés en quelques lignes de CSS (donc c'est aussi plus simple de comprendre ce qu'on fait, de débugger, etc…)
L'accès au doodle est inhibé pour les navigateurs qui ne supportent pas l'API javascript utilisé. Ici ça passe nickel sous Firefox 12 (Ubuntu 12.04), le doodle fonctionne.
Bref le problème c'est pas "Chrome ou pas Chrome", c'est "Navigateur supportant tels fonctions HTML5 ou pas".
Maintenant ils affichent aussi un message de pub pour chrome mais ça fait plusieurs mois qu'il est là celui-là.
Petite rectification pour les paranos : Les informations publiées sur G+ peuvent être lisibles par tous, mais on peut évidemment ne partager qu'avec certains cercles :-)
Je suis d'accord avec toi, je ne suis pas convaincu de l'utilité du vote électronique ou par internet.
Mais je mettais juste en évidence qu'il est possible d'aller assez loin avec la crypto pour construire un système aussi robuste que ce qu'on connaît aujourd'hui avec le vote papier.
Ben tu vas au bureau, tu montres ta carte d'identitée. Ensuite tu vas dans l'isoloire et tu votes sur la machine. Avant le dépouillement, la machine mélange les votes. Donc même si le type a l'entrée du bureau de vote note les noms dans l'ordre d'arrivée, il ne pourra pas retrouver ton vote.
Euh non, l'identification est simplement utilisée pour vérifier que le votant a le droit de voter. Mais ils garantissent qu'on ne peut pas faire le lien entre votant et vote.
Je ne suis pas sûr que ces limitations théoriques existent vraiment. Pour le vote électronique en tout cas, il existe ce genre de système qui permet à priori au votant de vérifier que son vote a été enregistré. J'ai pas vérifié en détail, mais ça a l'air solide et ça n'est pas proposé par des guignols.
Le problème c'est pas tellement la théorie, c'est plutôt que
1) Il faut être cryptographe pour vérifier vraiment le système
2) Personne n'a d'arguments satisfaisant pour justifier le vote électronique. Ca permet de gagner quelques heures au dépouillement, mais franchement voilà. Economiquement, c'est pas sûr que ça coûte moins cher, quand on inclut les coûts de développement, maintenance, audits, etc… Il faudrait commencer par définir un problème avec le vote papier.
3) Dans le cas du vote par internet, ça va être difficile de garantir que mon PC n'est pas infecté par un virus.
J'ai plus confiance dans le vote par correspondance que dans le vote par internet (en Suisse on a le vote par correspondance depuis un bout de temps). J'ai conscience que le vote par correspondance ne garantit pas la confidentialité/preuve du vote, mais le piratage a grande échelle me semble nettement plus difficile que sur un vote électronique.
Bref, pour les gens de l'étranger, je préférerais le vote par correspondance (si on a accès à internet, on a probablement accès à une poste) que le vote électronique.
Pour l'instant, d'après les "release notes", il s'agit uniquement de la sauvegarde du document JSON dans un champ text avec la particularité que le JSON est validé avant. Est-ce que quelqu'un sait s'il s'agit d'un premier pas vers l'ajout de fonctions dédiées au JSON permettant de le manipuler directement dans postgres ?
En fait, postgres va-t-elle devenir une base de données hybride SQL/NOSQL ?
Pour un gérant de Hedge Fund, non rentable ça doit vouloir dire bénéfice < 1000% du chiffre d'affaire. Les boîtes rentables aujourd'hui, c'est les bulles comme instagr.am et groupon. Les entreprises qui proposent des vrais services, c'est le passé
Il faut aussi garder à l'esprit que les résultats de ce site sont biaisés. Les gens susceptibles d'aller participer à ce type de scrutin virtuel ne sont pas forcément représentatif de la population (ils seront probablement plus intéressés par la politique, plus au fait des nouvelles technologies, probablement plus jeune).
Figures-toi que « la banque » ne peut pas créer de l'argent ex-nihilo: Pour te le prêter, elle doit déjà l'avoir (ou presque). Un exemple: Tu veux emprunter 10k pour te construire une hutte ecolo-socio-responsable dans une communauté artistique expérimentale sur les hauts plateaux du Larzac. Ta banque a également messieurs Dupont et Dupond qui possèdent respectivement une épargne bloquée sur 30 ans de 5k et 6k. Au total, la banque a assez d'argent pour te donner 10k immédiatement. Elle devra tout de même être en mesure de re-gagner ces 10k a terme au cas ou l'envie de disposer de leur argent prenait ses autres clients.
La banque n'a pas besoin d'avoir 10k à disposition pour te prêter 10k. Elle a besoin d'une fraction du montant du prêt (disons 20% => 2k) à garder en réserve. Pour les 8k restant, la banque peut les emprunter auprès de la banque centrale, ce qui crée de la monnaie scripturale. Si tous ceux qui ont déposé leur argent dans une banque vont en même temps tout retirer, la banque est dans la merde.
L'article wikipedia sur le système banquaire à réserve fractionnaire explique bien le processus : http://en.wikipedia.org/wiki/Fractional_reserve_banking
Après ça n'est pas forcément parce que les banques créent de la monnaie que ce sont des grosses méchantes qui entubent les contribuables (comme on veut nous l'explique sur des milliers de vidéos youtube). Je ne suis pas économiste et je suis très honnêtement incapable d'analyser l'intégralité du système (tout comme les types qui font des vidéos sur youtube). Il me semble cependant avoir l'avantage de favoriser les investissements. Si on demandait aux banques de garder l'intégralité des dépôts en réserve, ça serait plus difficile d'emprunter de l'argent. Après y'a probablement des abus, mais c'est un autre sujet.
Même si Google utilise MySQL, leur index est dans une base NoSQL (BigTable). Facebook est aussi à l'origine de Cassandra (base NoSQL) et ils sont passés à HBase pour leur fonction de recherche.
Donc c'est pas tant que les gens "reviennent" de NoSQL, c'est surtout que NoSQL n'est pas la réponse à tout et quand on a une application réellement relationelle, c'est souvent plus intelligent d'utilsier une base de données… relationelle.
En fait c'est comme souvent en informatique: il faut utiliser l'outil adapté, pas le dernier truc à la mode. Au début NoSQL a été adapté par plein de monde parce que ça permettait de "monter en charge comme Google". Sauf que pour 99% des applications, un serveur MySQL va probablement tenir la charge très bien.
J'avais lu un article (que je ne retrouve plus) d'un ingénieur qui bossait pour une de ces grosses boîtes 2.0 qui relevait qu'en fait pour monter en charge, la base de donnée n'est souvent pas le problème. C'est d'abord le code de l'appli qu'il faut revoir, la configuration des serveurs, du réseau, etc… Bref, à la limite, le jour ou la startup doit vraiment tenir un nombre énorme de connexions à la seconde, ils devront de toute façon tout revoir, même s'ils sont partis sur du NoSQL.
[^] # Re: Google fait de l'ouvert et du ferme aussi
Posté par Jux (site web personnel) . En réponse à la dépêche Sergey Brin dénonce les « cages dorées » de Facebook et Apple. Évalué à 5.
Il va falloir définir ouvert parce que je ne vois pas en quoi Native Client est fermé. Ok ils ont décidé d'une API tout seul, donc ce n'est pas un standard, mais à priori une énorme partie de Chrome est open source (Chromium) et il y a un site web pour les dev de navigateur intéressés à implémenter Native Client.
Ca n'a strictement rien à voir avec flash ou activex ou Adobe et Microsoft faisaient tout pour que personne d'autre ne puisse implémenter de plugin compatible.
Après, si vous pensez que Native Client n'est pas une bonne idée, libre à vous de ne pas l'implémenter et de proposer mieux. Mais ça ne veut strictement pas dire que Native Client est fermé.
# Pourquoi pas Python ?
Posté par Jux (site web personnel) . En réponse au journal Amis matheux, quel générateur d'exercice?. Évalué à 7.
Tu n'as pas l'air de porter python dans ton coeur, une raison à cela ?
Pourtant, pour avoir utilisé un peu sagemath et sympy pour du calcul formel (mais je suis informaticien, pas mathématicien), j'ai trouvé ça vraiment très intéressant et plutôt bien foutu. Etant écrit en python, c'est en plus facilement extensible et intégrable avec d'autres outils (matplotlib, numpy, scipy).
[^] # Re: C'est simple
Posté par Jux (site web personnel) . En réponse au journal Android ça pue c'est pas libre. Évalué à 4.
Y'a quand même pas mal de téléphones/tablets qui permettent d'installer facilement des ROMs alternatives. Au niveau téléphone, je pense que la série des Nexus de Google est le meilleur pari si on veut installer (ou faire soi-même) une ROM alternative.
Tu peux tout à fait aller télécharger les sources de cyanogenmod, les recompiler et installer ça. C'est clair qu'il faut des blobs binaires et c'est dommage, mais c'est la même chose pour pas mal d'ordinateurs qui tournent sous Linux (drivers wifi, graphiques), même si ça s'améliore.
Bref, on est d'accord qu'il faut mettre la pression pour que les fabriquants aillent vers des téléphones sans blobs binaires (comme il a fallu le faire avec les PC), mais de là à dire que Android c'est pas du tout libre, il y a un pas.
[^] # Re: Lui, il va avoir des problèmes...
Posté par Jux (site web personnel) . En réponse au journal Vote par Internet (oui, encore) : une première faille…. Évalué à 2. Dernière modification le 29 mai 2012 à 16:33.
La chaîne c'est :
[PC électeur] - [Routeur électeur] - [FAI électeur] - [FAI Etat] - [Serveur Etat]
[^] # Re: Revenir à la question fondamentale
Posté par Jux (site web personnel) . En réponse à la dépêche E-vote : les esprits se déchaînent en Suisse.. Évalué à 3.
Je pense que l'hypothèse la plus vraisemblable est moins catastrophique : C'est un mélange entre le fait de vouloir faire quelque chose de technologique parce que la technologie c'est bien. C'est de l'innovation, toussa. L'autre aspect, c'est l'espoir que ça augmente la participation des jeunes qui pourront voter depuis leur iPhone. Comme ça, on pourra voter entre deux like facebook, ça va être supaire.
[^] # Re: Lui, il va avoir des problèmes...
Posté par Jux (site web personnel) . En réponse au journal Vote par Internet (oui, encore) : une première faille…. Évalué à 9.
Il est un principe bien connu en sécurité qui dit que la sécurité d'une chaîne est égale à celle du maillon le plus faible.
Avec le vote par internet, on aura beau construire une chaîne super sécurisé entre l'état et le PC de l'utilisateur, le gros problème, celui qu'il sera vraiment très très très dur de résoudre, c'est la sécurité du PC de l'utilisateur. Si on est incapable de garantir la sécurité du PC de l'utilisateur, alors la jolie chaîne de sécurité qu'on a construite, elle est intéressante théoriquement, mais pratiquement ça ne vaut rien du tout.
[^] # Re: HTC Magic et performance
Posté par Jux (site web personnel) . En réponse au journal Newton Adventure évolue sur PC et débute sur Android. Évalué à 2.
L'autre solution, c'est de viser un téléphone plus récent qui a du JIT, un FPU, etc…
Mais ouais, faire tourner un jeu avec moteur physique sur un Magic, c'est un gros challenge je pense :-)
[^] # Re: HTC Magic et performance
Posté par Jux (site web personnel) . En réponse au journal Newton Adventure évolue sur PC et débute sur Android. Évalué à 2.
Pour le JIT, oui je voulais dire Android. Enfin, Android 1.6 sur Magic n'a pas de JIT. Si je me souviens bien, le JIT est apparu avec la version 2.X, mais même en installant ça sur un Magic (cyanogenmod par exemple), le JIT est désactivé car le téléphone n'as pas assez de RAM.
# HTC Magic et performance
Posté par Jux (site web personnel) . En réponse au journal Newton Adventure évolue sur PC et débute sur Android. Évalué à 10. Dernière modification le 25 mai 2012 à 19:40.
J'avais à l'époque développé un jeu de tank en 2D qui tourne bien sur un HTC Magic :
https://play.google.com/store/apps/details?id=net.fhtagn.zoob_demo
Les sources sont dispo sur github :
https://github.com/julienr/zoob
Un petit retour pour que ça tourne sur un Magic :
- J'ai utilisé C++ plutôt que Java. Le Magic n'a pas de JIT (trop peu de mémoire) et Java est donc super lent sur ce téléphone qui n'est déjà pas rapide…
- Quitte à rester en Java, il vaut mieux éviter Canvas et Drawable et travailler directement en OpenGL. Ca permet d'être plus fin dans ce qu'on veut et on gagne des perfs.
- Y'a tout un tas de petit "tips" pour écrire du code Java performant sur Android. Ca passe par l'utilisation de static final lorsque c'est possible, éviter les getter, etc :
http://developer.android.com/guide/practices/design/performance.html
- Mais si tu veux vraiment des bonnes perfs sur des téléphones bas de gamme, je crois que passer par C++ est nécessaire. C'est assez facile de faire du JNI sous Android. Pour mon jeu de tank, j'avais fais l'interface en Java et tout ce qui est jeu en C++.
Bonne chance !
[^] # Re: Entêtes binaires???
Posté par Jux (site web personnel) . En réponse à la dépêche En route pour HTTP/2.0. Évalué à 3.
Je me demande ceci dit à quel point l'attrait de HTTP vient de son mode texte. Le mode texte fait que pour un débutant, c'est facile à comprendre, on peut simplement lui montrer la requête.
Le mode texte fait que c'est aussi facile à implémenter dans la majorité des langages de prog (à coup de regexp ou de split, c'est super rapide à faire un parser HTTP). Si on compare ça à l'implémentation d'un parser pour Protobuf, ça fait une différence. Dès qu'on passe dans du binaire, on doit commencer à se poser des questions sur le décodage des entiers/float, etc… C'est pas la mort, mais on passe de "j'implémente un client en 30 minutes" à "je dois passer 2 jours à écrire mon parser".
Ceci dit, je suis un gros gros fan de Google Protobuf. J'utilise ça dans quasi tous mes projets à la place de JSON/XML, ça me permet d'avoir des messages typés avec un minimum de vérification et de cohérence.
Mais voilà, parfois, le texte c'est juste plus simple. Il faut aussi voir ce qu'on gagne en passant à du binaire. Si c'est pour garder la masse de headers inutiles, ça va pas changer grand chose.
[^] # Re: Entêtes binaires???
Posté par Jux (site web personnel) . En réponse à la dépêche En route pour HTTP/2.0. Évalué à 7.
Pour un exemple de protocol binaire est extensible tout en restant backward-compatible, tu peux jetter un oeil à Google Protocol Buffers par exemple :
http://code.google.com/p/protobuf/
[^] # Re: Bein ça existe déjà ...
Posté par Jux (site web personnel) . En réponse au journal Ô Joie, ô bonheur, ô miracle du W3C !. Évalué à 3.
Ca a l'air un peu plus poussé que boostrap dans le sens où ça permet de donner des limites min/max à l'extension des div (d'où le nom flex).
Globalement, ça permet surtout de s'épargner les nombreux hack de boostrap et de faire des layouts un peu avancés en quelques lignes de CSS (donc c'est aussi plus simple de comprendre ce qu'on fait, de débugger, etc…)
[^] # Re: Euh
Posté par Jux (site web personnel) . En réponse au journal Les gros sabots de Google. Évalué à 4.
L'accès au doodle est inhibé pour les navigateurs qui ne supportent pas l'API javascript utilisé. Ici ça passe nickel sous Firefox 12 (Ubuntu 12.04), le doodle fonctionne.
Bref le problème c'est pas "Chrome ou pas Chrome", c'est "Navigateur supportant tels fonctions HTML5 ou pas".
Maintenant ils affichent aussi un message de pub pour chrome mais ça fait plusieurs mois qu'il est là celui-là.
[^] # Re: Facebook
Posté par Jux (site web personnel) . En réponse au journal petite analyse des réseaux sociaux. Évalué à 3.
Petite rectification pour les paranos : Les informations publiées sur G+ peuvent être lisibles par tous, mais on peut évidemment ne partager qu'avec certains cercles :-)
[^] # Re: et le vote papier ?
Posté par Jux (site web personnel) . En réponse au journal Le vote par internet, c'est encore mieux quand c'est bien fait.... Évalué à 2.
Je suis d'accord avec toi, je ne suis pas convaincu de l'utilité du vote électronique ou par internet.
Mais je mettais juste en évidence qu'il est possible d'aller assez loin avec la crypto pour construire un système aussi robuste que ce qu'on connaît aujourd'hui avec le vote papier.
[^] # Re: et le vote papier ?
Posté par Jux (site web personnel) . En réponse au journal Le vote par internet, c'est encore mieux quand c'est bien fait.... Évalué à 2.
Ben tu vas au bureau, tu montres ta carte d'identitée. Ensuite tu vas dans l'isoloire et tu votes sur la machine. Avant le dépouillement, la machine mélange les votes. Donc même si le type a l'entrée du bureau de vote note les noms dans l'ordre d'arrivée, il ne pourra pas retrouver ton vote.
C'est comme avec le vote papier ça en fait.
[^] # Re: et le vote papier ?
Posté par Jux (site web personnel) . En réponse au journal Le vote par internet, c'est encore mieux quand c'est bien fait.... Évalué à 2.
Euh non, l'identification est simplement utilisée pour vérifier que le votant a le droit de voter. Mais ils garantissent qu'on ne peut pas faire le lien entre votant et vote.
[^] # Re: et le vote papier ?
Posté par Jux (site web personnel) . En réponse au journal Le vote par internet, c'est encore mieux quand c'est bien fait.... Évalué à 5.
Je ne suis pas sûr que ces limitations théoriques existent vraiment. Pour le vote électronique en tout cas, il existe ce genre de système qui permet à priori au votant de vérifier que son vote a été enregistré. J'ai pas vérifié en détail, mais ça a l'air solide et ça n'est pas proposé par des guignols.
Le problème c'est pas tellement la théorie, c'est plutôt que
1) Il faut être cryptographe pour vérifier vraiment le système
2) Personne n'a d'arguments satisfaisant pour justifier le vote électronique. Ca permet de gagner quelques heures au dépouillement, mais franchement voilà. Economiquement, c'est pas sûr que ça coûte moins cher, quand on inclut les coûts de développement, maintenance, audits, etc… Il faudrait commencer par définir un problème avec le vote papier.
3) Dans le cas du vote par internet, ça va être difficile de garantir que mon PC n'est pas infecté par un virus.
[^] # Re: Rat des villes et rat des champs
Posté par Jux (site web personnel) . En réponse au journal Le vote par internet, c'est encore mieux quand c'est bien fait.... Évalué à 3.
J'ai plus confiance dans le vote par correspondance que dans le vote par internet (en Suisse on a le vote par correspondance depuis un bout de temps). J'ai conscience que le vote par correspondance ne garantit pas la confidentialité/preuve du vote, mais le piratage a grande échelle me semble nettement plus difficile que sur un vote électronique.
Bref, pour les gens de l'étranger, je préférerais le vote par correspondance (si on a accès à internet, on a probablement accès à une poste) que le vote électronique.
[^] # Re: JSON !
Posté par Jux (site web personnel) . En réponse au journal Postgresql 9.2 Beta 1. Évalué à 2.
Pour l'instant, d'après les "release notes", il s'agit uniquement de la sauvegarde du document JSON dans un champ text avec la particularité que le JSON est validé avant. Est-ce que quelqu'un sait s'il s'agit d'un premier pas vers l'ajout de fonctions dédiées au JSON permettant de le manipuler directement dans postgres ?
En fait, postgres va-t-elle devenir une base de données hybride SQL/NOSQL ?
[^] # Re: Modèle économique non rentable...
Posté par Jux (site web personnel) . En réponse au journal Google et FaceBook vont disparaitre !. Évalué à 10.
Pour un gérant de Hedge Fund, non rentable ça doit vouloir dire bénéfice < 1000% du chiffre d'affaire. Les boîtes rentables aujourd'hui, c'est les bulles comme instagr.am et groupon. Les entreprises qui proposent des vrais services, c'est le passé
[^] # Re: Médiane/Moyenne
Posté par Jux (site web personnel) . En réponse au journal Vote de Valeur : and the winner is.... Évalué à 5.
Ah ok, j'avais loupé ce détail pratique. Effectivement, c'est nettement plus représentatif qu'une version uniquement numérique !
[^] # Re: Médiane/Moyenne
Posté par Jux (site web personnel) . En réponse au journal Vote de Valeur : and the winner is.... Évalué à 8.
Il faut aussi garder à l'esprit que les résultats de ce site sont biaisés. Les gens susceptibles d'aller participer à ce type de scrutin virtuel ne sont pas forcément représentatif de la population (ils seront probablement plus intéressés par la politique, plus au fait des nouvelles technologies, probablement plus jeune).
[^] # Re: Dette
Posté par Jux (site web personnel) . En réponse au journal [HS] Politique naïve et incohérences. Évalué à 9.
La banque n'a pas besoin d'avoir 10k à disposition pour te prêter 10k. Elle a besoin d'une fraction du montant du prêt (disons 20% => 2k) à garder en réserve. Pour les 8k restant, la banque peut les emprunter auprès de la banque centrale, ce qui crée de la monnaie scripturale. Si tous ceux qui ont déposé leur argent dans une banque vont en même temps tout retirer, la banque est dans la merde.
L'article wikipedia sur le système banquaire à réserve fractionnaire explique bien le processus : http://en.wikipedia.org/wiki/Fractional_reserve_banking
Après ça n'est pas forcément parce que les banques créent de la monnaie que ce sont des grosses méchantes qui entubent les contribuables (comme on veut nous l'explique sur des milliers de vidéos youtube). Je ne suis pas économiste et je suis très honnêtement incapable d'analyser l'intégralité du système (tout comme les types qui font des vidéos sur youtube). Il me semble cependant avoir l'avantage de favoriser les investissements. Si on demandait aux banques de garder l'intégralité des dépôts en réserve, ça serait plus difficile d'emprunter de l'argent. Après y'a probablement des abus, mais c'est un autre sujet.
[^] # Re: Budget RAM
Posté par Jux (site web personnel) . En réponse à la dépêche Petit état des lieux du NoSQL. Évalué à 10.
Même si Google utilise MySQL, leur index est dans une base NoSQL (BigTable). Facebook est aussi à l'origine de Cassandra (base NoSQL) et ils sont passés à HBase pour leur fonction de recherche.
Donc c'est pas tant que les gens "reviennent" de NoSQL, c'est surtout que NoSQL n'est pas la réponse à tout et quand on a une application réellement relationelle, c'est souvent plus intelligent d'utilsier une base de données… relationelle.
En fait c'est comme souvent en informatique: il faut utiliser l'outil adapté, pas le dernier truc à la mode. Au début NoSQL a été adapté par plein de monde parce que ça permettait de "monter en charge comme Google". Sauf que pour 99% des applications, un serveur MySQL va probablement tenir la charge très bien.
J'avais lu un article (que je ne retrouve plus) d'un ingénieur qui bossait pour une de ces grosses boîtes 2.0 qui relevait qu'en fait pour monter en charge, la base de donnée n'est souvent pas le problème. C'est d'abord le code de l'appli qu'il faut revoir, la configuration des serveurs, du réseau, etc… Bref, à la limite, le jour ou la startup doit vraiment tenir un nombre énorme de connexions à la seconde, ils devront de toute façon tout revoir, même s'ils sont partis sur du NoSQL.