D'où le bordel ambiant et l'incapacité à respecter une règle aussi bête que faire la queue.
C'est marrant je le voyais pas comme ça. Il me semblait que c'était plus dû à la loi de la jungle qui règne dans ce pays. Chacun pour sa gueule, le premier servit à eu raison. Et si t'es paraplégique, dommage pour toi fallait te lever plus tôt que les autres.
Muè, je ne suis pas certain qu'il veulent contrôler les individus, mais les effets de masse.
A ce petit jeu là, contrôler le tuyau est bien simple et efficace que de tenter de contrôler le support.
En plus les (citoyens) chinois, pour aussi docile qu'ils sont, n'en sont pas pour autant complètement débile.
C'est une bonne opération pour canonical, passer par le gouvernement est le meilleur moyen de se donner une assise stable dans un pays aussi vaste, aussi bien géographiquement que culturellement.
Enfin si vraiment ils souhaitent accéder au device de manière ponctuel ils utiliseront des 0days, le vol, ou du social engineering.
Le gouvernement à déjà fais montre de son niveau d'expertise dans ces domaines lors de l'affaire google.
Honnêtement nous faire choisir entre la console, la sécurité, le gestionnaire de paquets, la communauté, l'esprit et tous les autres,
c'est dur. difficile. mal honnête ! Impossible !!
Linux c'est une expérience pleine et entière, et c'est pour tout cela qu'on l'utilise.
Moi, le kernel tout seul, sans gestionnaire de paquets, ni console, ni hacker, ça me plaît pas trop!
Même imprimé sur du papier calque, raf =D
Je signe tout de suite.
Je ferais même rajouter une clause pour distribuer certaines librairies javascript avec les navigateurs afin que plus jamais elle n'ai besoin de transférer sur le réseau et solutionner un petit plus encore ses problèmes de chargement.
Ceci dit, tu as eu un plus de retours, mais c'est p'tet pas ceux là que tu souhaitais voir pour te motiver, ou autre = )
Encore merci pour le temps que tu as pris à partager ces projets !
pourquoi ne pas transformer ce post en journal ?
Je me dit que sa visibilité sera bien meilleure et les retours plus nombreux.
Le sujet m’intéresse beaucoup, c'est un peu bas niveau pour moi, mais je sais que j'ai matière à en apprendre.
En plus tu as la plume agréable à lire.
En tout cas j'accroche à ton discours à 200%.
Une approche qui ne casse pas l'existant mais l'améliore, sans dénaturer le JS.
En une phrase, Faudrait être ocn pour passer à côté.
De mon expérience la partie TPE n'est vraiment pas difficile.
Les banques font des docs très pratique avec en général des exemples à copier, coller, lire attentivement, modifier, déplacer par ftp, et voilà.
Pour ce qui concerne la sécurité, tu seras surtout dépendant de ton prestataire de paiement.
Toutes les solutions que j'ai rencontré sont vigilantes à ce sujet, et t'indiquent les faiblesses de leurs implémentations que tu devras couvrir via quelques configuration bien connues et documentées.
Après à savoir si cela est sécurisé, je ne penses pas, mais le monde s'en contente, alors bon, ce qu'on en dira…
Au sujet de tes solutions e-commerce, je ne sais pas, j'évite comme la peste les usines à gaz qui ne prennent pas mes notes ni ne me font le café.
Partant de là… Mon expérience est trop restreinte.
bref, moi c'est plus l'aspect japonais du site qui m'interroge.
La livraison, le modèle de facture tout cela.
Voir plus simplement, vérifier son travail avec des contenus écris en japonais.
Comme de la perplexité en perspective.
Alors je sais pas ou tu trouves ta définition de libre, mais c'est marqué nulle part "projet qui n'a pas de main d'oeuvre".
Ah beh rien ne force personne à développer sur linux. Et si demain les gens venaient à décider qu'il y à de meilleurs activités dans la vie, il ne s'y prendront pas à deux fois avant de changer de chemin.
Par contre, n'importe quelle société éditrice de logiciel trouvera toujours des gens pour bosser sur ces projets, puisqu'ils sont obligés de payer leurs factures à la fin du mois.
Si je dit "on ne garde qu'un bureau, et c'est gnome", est ce que je vais avoir plus de gens pour bosser sur gnome ? Non.
voui. A croire que les dévs apporte plus d'importance à leurs idées d'implémentation plutôt qu'au projet linux dans son entièreté.
Le projet linux devant alors s'adapter aux projets qui le composent plutôt que l'inverse.
N'est ce pas là la difficulté majeure face à un windows ou un mac ?
Oui, linux, ou pluot certaines distributions sont prêtes pour le bureau.
Elles savent même se faire aguicheuse.
La dessus, je n'ai pas de doute.
Là où j'ai plus de doutes c'est quand à la capacité de la communauté à maintenir autant de
versions (au sens du numéro, historique)
distro
applications
ET en même temps
arriver à fournir les dernières nouveautés pour l'utilisateur
capitaliser l'existant dans un monde qui change tellement vite
Moi il me semble que le temps perdu à maintenir certaines querelles est vraiment une des raisons qui empêche se projet de s'épanouir plus encore.
Je n'y connais que peu de choses, mais à quoi bon supporter , quoi, 3 4 plus ? boot loader.
lilo, grub, machin, truc et bidule chouette…
Avec à peu près tous le même objectif,
booter un linux, un unix et le reste.
C'est un peu contradictoire comme attitude.
Le libre est par définition en manque de main d'oeuvre, et on s'en rajoute en se disant que c'est plus mieux de maintenir le double de code pour la même fonctionnalité.
Je sais pas…
Enfin, je sais bien que cette diversité est le prix d'une modularité à toute épreuve, c'est ce que je veux croire, mais il me semble que ce n'est pas rationnel pour un sous.
Je sais qu'en tout cas que ces quelques reproches, constats, sont vraiment généralisable dans le monde linux.
The rationale behind the ability to turn the mechanism on and off, and to initiate cycle collection yourself, is that some parts of your application could be highly time-sensitive. In those cases, you might not want the garbage collection mechanism to kick in. Of course, by turning off the garbage collection for certain parts of your application, you do risk creating memory leaks because some possible roots might not fit into the limited root buffer. Therefore, it is probably wise to call gc_collect_cycles() just before you call gc_disable() to free up the memory that could be lost through possible roots that are already recorded in the root buffer. This then leaves an empty buffer so that there is more space for storing possible roots while the cycle collecting mechanism is turned off.
Je trouvais ton idée séduisante, mais après lecture de la doc, un peu moins.
tu fais es echos pour écrire ta donnée sur la sortie standard, mais les 24mo reste dans le buffer d'apache tant que tu n'as pas intimé l'ordre à apache de se vider chez le client.
Il précise dans la doc qu'avec mod_gzip activé sur apache, cet appel de flush restera sans effet.
Les commentaires sur php.net, comme souvent, sont précieux de détails divers et variés à consulter obligatoirement.
Autrement, avec le bout de code fournit, je ne vois pas ce qui pourrait bugger. Et n'ayant pas d'expérience de pgsql, je ne saurais connaître ses subtilités.
Dans ta situation, j’essaierais de virer le bruit de mon script pour le focaliser sur un subset du code suffisamment restreint pour tenter d'identifier l'origine du problème.
Dans ton exemple je ferais une version qui ne fais que exécuter / boucler - traiter les résultats de requêtes, sans echo, ni sauvegarde en variable.
Si rien ne se dévoile, alors une autre version avec les echos ect.
Et ainsi de suite.
Finalement, étant donné un numéro de version de php (j'imagine qu'étant sous débian tu ne tournes pas sur la toute dernière version) tu pourrais aussi vérifier les changelogs pour voir si un bug ne semble pas te concerner de près ou de loin, http://www.php.net/ChangeLog-5.php
il est assez régulier qu'un ou plusieurs leaks soit corrigés.
On aborde ces nouveautés complètement différemment.
Tu as un point de vue purement utilisateur, et en cela on est d'accord sur à peu près tout ce que tu dis.
A un point près, qui n'a rien à voir avec l'expérience utilisateur,
J'ai l'impression que la défense des "techno web" est contradictoire:
…
-d'un autre côté, dès qu'on dit ça, on réponds "oui mais non, en fait, les techno web sont des applications natives avec un framework basé sur l'html5 et le javascript", mais dans ce cas, en quoi est-ce différent des applications natives traditionnelles (déployée et maintenue à jour via le gestionnaire de dépôt) ?
Ah oui définitivement les technos web n'ont rien inventé. Le principe ajax par exemple c'est faisable en .net ou Qt. Les designs patterns sont les mêmes. Les pratiques de tests et contrôles identiques.
Juste un détail mineur.
Toutes les technos desktop, disons client lourd, sont des tueurs de créativité.
C'est à dire que de part leurs degré de complexité, ces technos sont inaccessible à tout un tas de gens qui ont le besoin, ou le désire, d'écrire une application.
Et ça le HTML, c'est une des raisons de son existence, de son succès. On pensera par ailleurs à php dans la même veine.
C'est le petit détail mineur qui me semble être un killer feature.
Pour le reste, j'ai le sentiment que ce virage, c'est aussi le moment de repensé l'intégration du bureau dans l'écosystème logiciel d'aujourd'hui.
Avant on se fiché d'internet, après on à eu msn, pis vint l'intégration de facebook, twitter ect dans le bureau. Là on en est au moment où le web entre dans le bureau, et pour que ce soit possible, les développeurs webs ont juste besoin d'avoir des spécifications de webservice à suivre.
Hors ce travail là, c'est au développeur de l'OS de le fournir.
C'est du niveau des variables de PATH.
Un problème très concret, j'ai besoin de lancer une instance Java, en mode multiplateforme.
Aujourd'hui pour ce faire, en bash, cela donnes :
OS_TYPE=`"$UNAME" -s`
# ---------------------------------------------------------------------
# Locate a JDK installation directory which will be used to run the IDE.
# Try (in order): WEBIDE_JDK, JDK_HOME, JAVA_HOME, "java" in PATH.
# ---------------------------------------------------------------------
if [ -n "$WEBIDE_JDK" -a -x "$WEBIDE_JDK/bin/java" ]; then
JDK="$WEBIDE_JDK"
elif [ -n "$JDK_HOME" -a -x "$JDK_HOME/bin/java" ]; then
JDK="$JDK_HOME"
elif [ -n "$JAVA_HOME" -a -x "$JAVA_HOME/bin/java" ]; then
JDK="$JAVA_HOME"
else
JAVA_BIN_PATH=`which java`
if [ -n "$JAVA_BIN_PATH" ]; then
if [ "$OS_TYPE" = "FreeBSD" ]; then
JAVA_LOCATION=`JAVAVM_DRYRUN=yes java | "$GREP" '^JAVA_HOME' | "$CUT" -c11-`
if [ -x "$JAVA_LOCATION/bin/java" ]; then
JDK="$JAVA_LOCATION"
fi
elif [ "$OS_TYPE" = "SunOS" ]; then
JAVA_LOCATION="/usr/jdk/latest"
if [ -x "$JAVA_LOCATION/bin/java" ]; then
JDK="$JAVA_LOCATION"
fi
elif [ "$OS_TYPE" = "Darwin" ]; then
JAVA_LOCATION=`/usr/libexec/java_home`
if [ -x "$JAVA_LOCATION/bin/java" ]; then
JDK="$JAVA_LOCATION"
fi
fi
if [ -z "$JDK" -a -x "$READLINK" ]; then
JAVA_LOCATION=`"$READLINK" -f "$JAVA_BIN_PATH"`
case "$JAVA_LOCATION" in
*/jre/bin/java)
JAVA_LOCATION=`echo "$JAVA_LOCATION" | xargs dirname | xargs dirname | xargs dirname` ;;
*)
JAVA_LOCATION=`echo "$JAVA_LOCATION" | xargs dirname | xargs dirname` ;;
esac
if [ -x "$JAVA_LOCATION/bin/java" ]; then
JDK="$JAVA_LOCATION"
fi
fi
fi
fi
if [ -z "$JDK" ]; then
echo "ERROR: cannot start PhpStorm."
echo "No JDK found. Please validate either WEBIDE_JDK, JDK_HOME or JAVA_HOME environment variable points to valid JDK installation."
echo
echo "Press Enter to continue."
read IGNORE
exit 1
fi
pour trouver
un simple chemin d'accès,
d'un exécutable disponible sur 90% des appareils,
et l'exemple ne concerne que le monde linux friendly.
Honnêtement, on peut faire plus simple ?
-- Et je dirais même,
-- on peut faire simple à consommer pour le développeur d'application, et plus libre à développer pour le développeur système.
Bon bah le développeur de demain il à besoin de disposer d'un set de services simples et fonctionnels pour réaliser des tâches communes, récurrentes afin de laisser sa créativité parler.
Plutôt que de perdre son temps à gérer ces querelles d'informaticiens, ou bien encore des détails d'implémentation technique du style "out of memory".
Ces choses qui tuent la créativité instantanément par irradiation mortelle.
-le fait que le service soit centralisé sur des serveurs ayant peu de chance de tomber en panne est un inconvénient: cela signifie que les minorités n'auront pas droit à un outil qui correspond à leur gout et méthode de travail.
J'ai pas bien compris car aujourd’hui si je veux me monter un travis (serveur d'intégration continue) spécifique, je suis obliger de prendre le code, de le descendre et de le setup sur ma machine. De le personnaliser et enfin de le déployer sur une autre machine pour le mettre à dispo de ma communauté.
Demain, j'aurais une signature de webservice pour l'ui.
une définition d'implémentation pour le serveur.
Après, soit le webservice n'est implémenté que de manière fermer, et n'est consommable que via un seul provider.
Soit j'ai à disposition une version libre de son implémentation me permettant de déployer le serveur à ma guise.
Mais dans tous les cas, à minima, mon ui en est indépendante de son implémentation physique et logique, multi device, hébergée en ligne / hors ligne ect ect
bref je peux me brander,
et pour peu que je soit un mec cool, je mets à disposition mon implémentation du serveur pour que chacun puisse le déployer dans son coin.
Bon de toute façon,
le html et ses potes s'imposera.—Notes que, non ce n'est pas un troll, mais que oui, c'est une affirmation sans fondements évident.
Alors après oui on peut continuer à produire des Qt ou des GTK pour faire réaliser certains applications qui aujourd'hui nous semble hors de porter des technos web.
J'ai dans l'idée que ces gens là finiront par améliorer les technos web pour arriver à leurs fins et s'y intégrer, ne serait ce que par un effet mouton de panurge.
c'est intéressant cette réflexion du service en ligne / Hors ligne.
Il ne me semblait pas que technos web === en ligne.
Pour moi il devrait y avoir le fournisseur de mail (orange) avec un api, le fournisseur d'UI (MOI! developpeur du dimanche).
Là il y a de la place pour le libre. Chacun pouvant créer son interface.
Après si par ailleurs je n'ai pas les moyens d'héberger mon UI sur des grosses fermes,
Ben figures toi qu'on peut déporter l'hébergement chez le client !
Dingue…. C'est lui qui host l'appli et qui cause en direct avec son fournisseur de mail.
Et en tant que développeur d'UI pour peu que j'ai un installeur capable, qu'est ce qui m’empêche de m'éclater en requiérant un package de bdd nosql et faire mes additifs ?
Le multi plateforme tend à être de plus en plus workable et rien ne m'en empêche.
Découpons, franchement, les applis, ce ne peut pas être si mauvais.
Même si c'est un peu lourd sur certains points…….. on ne peut pas tout avoir, pas tout de suit semble t'il.
Sauf que, ce n'est plus vraiment le cas. Les toolkits graphiques sont passé à des interfaces déclaratives et ça rend les designes bien plus simple que tu semble croire.
Mon expérience de ces technos est très peu approfondie, un peu de .net, un peu de QT (c'était à l'arrivé de QML mais je n'en ai pas fais à ce moment là), un peu de glade, et après des trucs genre pango (pour les fonts si j'ai bon souvenir).
Bref, oui il y à les tk, qui t'aides beaucoup, mais tu dois encore connecter les events.
Par exemple en QT les signals, ont à priori, extrêmement simplifié le problème, sauf que je me suis battu avec à cause des spécificités de C / C++ eect. (les pointeurs tousssa, Oui j'ai un niveau de m*** en C).
Et puis après il faut effectivement programmer les fonctionnalités. Rebolotte il faut se frotter à tout un tas de concepts qui pour moi sont un vrai problème.
Il reste la partie programmatique mais pour ça tu utilise le binding que tu veux (paf QML + Js et c'est partie).
Faudrait que je le testes pour de vrai. Mais je ne peux m’empêcher que cette solution est sous optimale par rapport à une refondation plus profonde comme a pu le faire des projets comme GO ou nodejs (langage que je manipules, mieux que le D, C, c# ect).
L'avantage c'est que tu n'a pas les contraintes liée à HTTP (asynchronisme, le découpage client/serveur de l'application, etc).
Moi je suis très content de ce découplage. Enfin, les technos actuelles purement à base de MVC sont à mon opinion pas bonne du tout.
Mais avec le MVVM pour le client, le MVC pour le serveur tu peux arriver à rendre chacun de ces aspects indépendant, mais pas découplé. J'insiste la dessus, indépendant et non découplé.
Après j'ai l'expérience d'une appli bureau réseau, grosse artillerie, .net Remoting.
Bah je me suis bien amusé au début, après qu'est ce que j'ai ramé……. Je n'ai pas sentit le power to build, mais plutôt le power to debug.
La différence à mon humble avis c'est que l'un est une question de présentation et d’expérience utilisateur (limiter la longueur des lignes etc) et l'autre est de la cosmétique.
Oui probablement. Mais l'un dans l'autre, les toolkits avec tous les efforts qu'ils ont fait ne sont jamais parvenus à fournir un environnement de développement qui permette à l'industrie non informatique de personnaliser leurs applications bureaux.
Là où le web ne travail qu'à cela depuis 20 ans.
Je ne dis pas qu'ils ne sont pas capable sur le desktop, cela ne s'est pas produit.
Et encore que s'attacher au problème de la beauté de l'ui n'est que le pendant du problème de la gestion multi plateforme.
Dans les deux technos web et desktop le multi plateforme est possible.
Dans les deux technos il y à des plus et des moins.
Je considère que les moins du web sont plus attrayants, plus facile à affronter, que les moins du desktop.
Même des technos comme GO ou nodejs qui sont pourtant toute fraîche et pensée pour aller à l'encontre de ces difficultés ne sont pas encore parvenus à une compatibilité sans défaut sur des concepts identiques.
Pour diverses raisons, ce n'est pas tant la question ici.
Tu entends quoi par « DP » ? Tu as des pointeurs sur le mvvm ? J'ai du mal à le différencier du mvc.
Design pattern, pensais tu à autre chose ?
Pour ce qui est de la différence entre mvvm et mvc, j'ai longtemps était dans le flou personnellement. Notamment parce qu'on présente mvvm comme une évolution de mvc cf http://en.wikipedia.org/wiki/MVVM
Alors qu'à mon humble avis ils sont surtout complémentaires et c'est ainsi qu'il faudrait en parler.
Je l'ai compris après avoir builder une application en utilisant knockout.
Éventuellement une bonne vidéo de démo de MVVM à regarder est celle de meteor (recherhe google : meteor js screencast)
bref, le model-view view-model n'intervient que pour synchroniser la vue par rapport au statut d'un modèle de vue (le modele et sa vue dans MVVM).
Car c'est bien d'un modele de Vue dont on parle. Pas d'un modèle de donnée que l'on mets dans un sgbd.
AMHA ce n'est pas un subset, ni une copie identique (penser REST), mais une ré interprétation (on formate, on tri, on prend deux services, on combine et paf un nouveau modèle de vue ect), et une spécialisation (le client de MVVM injecte son état dans son modèle).
Ce client MVVM, discute avec un Controleur de MVC, qui encapsule en entrée / sortie son Modèle de sgbd.
Sa Vue de MVC ne doit "que" formater la réponse en JS / XML / BIN / ce-qu'il-te-plait
Le Contrôleur de MVC, aussi complexe que soit ces règles de gestion, est relativement binaire il répondra toujours succès ou échec. (Les autres trucs 302 404 de HTTP ect c'est pas vraiment son problème à MVC amha, enfin sauf si il décide de ré implémenter une partie de son serveur web lui même… c'est une histoire connue dont je ne parlerais pas)
Le client MVVM peut dès lors consommer ces deux états afin de décider de l'affichage sur sa Vue.
Là où sa devient vraiment beau, c'est à voir l'implémentation de meteor
qui enregistre et applique immédiatement la modification sur son modèle de vue,
envoie sa demande à son contrôleur de MVC côté serveur,
plus tard lorsque le serveur répond, le client MVVM procède alors,
soit à un commit local,
soit un rollback, qui provoque alors une mise à jour de la vue.
Le problème c'est que pour que cela fonctionne bien il faut un pont entre l'implémentation de MVC et MVVM afin de ne pas dupliquer certaines choses comme le routing par exemple.
Il faut qu'il puisse partager des informations. Hors avec des bases en php, asp, java c'est compliqué à moins de passer par des sérialisations, mais alors sa réduit la liberté du développeur.
des réflexions comme sa, à basher, corriger, discuter avec plaisir.
Bon je peux plus m'éditer, alors je me parle tout seul, note que je commence à avoir l'habitude ce n'est pas la première fois,
toujours au sujet de meteor, une petite quote qui me plait beaucoup.
Seven Principles of Meteor
- Data on the Wire. Don't send HTML over the network. Send data and let the client decide how to render it.
- One Language. Write both the client and the server parts of your interface in JavaScript.
- Database Everywhere. Use the same transparent API to access your database from the client or the server.
Latency Compensation. On the client, use prefetching and model simulation to make it look like you have a zero-latency connection to the database.
- Full Stack Reactivity. Make realtime the default. All layers, from database to template, should make an event-driven interface available.
- Embrace the Ecosystem. Meteor is open source and integrates, rather than replaces, existing open source tools and frameworks.
- Simplicity Equals Productivity. The best way to make something seem simple is to have it actually be simple. Accomplish this through clean, classically beautiful APIs.
La vidéo de meteor est absolument géniale.
En plus ils ont vraiment fais les choses bien à mon goût.
C'est simple et direct comme du html, c'est pensé pour faire face aux problèmes de latence, ça produit des livrables indépendants.
Tout simplement mortel.
Et précisément ce que je cherche.
Cependant, et j'ai eu cette réflexion dès qu'ils ont parlé de mongodb, il me semble que c'est difficile de l'intégrer dans un existant avec des sgbdr bien établit et bien remplit.
Le changement d'ui t'imposes de migrer tes données. Ça, c'est pas cool.
En tout cas à part imiter une interface mongodb dans les modèles consommés par météor, je ne vois pas bien comment faire dans l'immédiat.
En quoi c'est plus simple d'utiliser un descripteur en json plutôt qu'un descripteur en html pour faire ce qui ressemble à un menu dropdown ?
Sinon je préférerais tourner sur une version compilée du site pour sentir mon coeur battre.
Là…. soso. Ça me donne le sentiment d'une usine à gaz qui s'assume pleinement.
Bon après c'est p'tet le cas.
Clair que le gamin ne peut comprendre la signification.
Mais tout de même c'est un âge formateur pour le cerveau et la mémoire.
Dans le doute des interactions que cela peut avoir, si j'avais un gamin, je préfère m'abstenir.
Un chercheur du cnrs c'est intéressé à l'impact de la télé sur la vie, en général.
Deux points intéressants, amha,
- Aux usa durant leurs scolarité tous les étudiants passe un test. C'est un test pour observer le degré moyen d'intelligence des étudiants. Le fait est, que lorsque la télé est introduite aux usa (j'ai pas la date en tête..), il a été constaté que les résultats de ce test ont instantanément perdu 10 points. *32'22
- la télé agit comme un excitant pour le cerveau qui doit sans cesse faire appel aux mécanismes du réflexe. Hors il se trouve que pour les jeunes enfants cet appel répété soit nocif dans leur apprentissage.
Je n'étais même pas au courant de cette histoire de no follow avec le pr et les pertinantations.
Je dois dire que je serais content d'avoir des posts des éditions diamond ou basta (connais pas celui là) lorsqu'ils sortent une revue.
Après tout c'est l'actualité du libre….
Ne suffirait il pas de créer une catégorie spéciale pour s'arranger de tout ces problèmes de pr ect ?
J'y verrais bien une petite news régulière de misc………
Enfin je ne voulais pas te qualifier de terroriste dans mes propos, il y à eu mésentente, mes excuses les plus plates.
La liberté est à l'homme ce que les ailes sont à l'oiseau
Le meilleur moyens de prendre la grosse tête, s'envoler comme une montgolfière, et de s'écraser la gueule après une longue décente. Mais jusqu'ici tout va bien ; )
C'est le bon peuple m'sieur. Celui qui vote, ont va pas leurs taper dessus si ils ouvrent leurs gueules pour de telles conneries. Qu'ils continuent, au moins ils ne regardent pas la lune.
et de s'en plaindre, ils sont stupide ces deux là.
Car après tout chacun fait ce qu'il veut de l'éducation de ces gamins.
C'est surtout qu'ils s'en étonnent que je trouve stupide, la légende d'une des photos, "Devant son ordinateur Alexandre de franca n'en revient toujours pas".
Mais !!! c'est tellement stupide comme attitude que même le commentaire en est d'une niaiserie pathétique..
# rien à voir
Posté par maboiteaspam . En réponse au journal Canonical s'attaque au marché Chinois. Évalué à 1.
C'est marrant je le voyais pas comme ça. Il me semblait que c'était plus dû à la loi de la jungle qui règne dans ce pays. Chacun pour sa gueule, le premier servit à eu raison. Et si t'es paraplégique, dommage pour toi fallait te lever plus tôt que les autres.
# malgre tout
Posté par maboiteaspam . En réponse au journal Kylin, l'Ubuntu chinois. Évalué à 2. Dernière modification le 26 mars 2013 à 12:03.
Muè, je ne suis pas certain qu'il veulent contrôler les individus, mais les effets de masse.
A ce petit jeu là, contrôler le tuyau est bien simple et efficace que de tenter de contrôler le support.
En plus les (citoyens) chinois, pour aussi docile qu'ils sont, n'en sont pas pour autant complètement débile.
C'est une bonne opération pour canonical, passer par le gouvernement est le meilleur moyen de se donner une assise stable dans un pays aussi vaste, aussi bien géographiquement que culturellement.
Enfin si vraiment ils souhaitent accéder au device de manière ponctuel ils utiliseront des 0days, le vol, ou du social engineering.
Le gouvernement à déjà fais montre de son niveau d'expertise dans ces domaines lors de l'affaire google.
Mes 2 cents depuis sh.
a+
# ce sondage n'est pas fair
Posté par maboiteaspam . En réponse au sondage Selon vous, quel est l'avantage d'un système libre type GNU/Linux sur un ordinateur de bureau ?. Évalué à 4.
Honnêtement nous faire choisir entre la console, la sécurité, le gestionnaire de paquets, la communauté, l'esprit et tous les autres,
c'est dur. difficile. mal honnête ! Impossible !!
Linux c'est une expérience pleine et entière, et c'est pour tout cela qu'on l'utilise.
Moi, le kernel tout seul, sans gestionnaire de paquets, ni console, ni hacker, ça me plaît pas trop!
Même imprimé sur du papier calque, raf =D
a+
# Comme je n'ai pas envi de refaire le monde
Posté par maboiteaspam . En réponse au journal Réflexion sur ASM.js ou quand le javascript deviens enfin performant :. Évalué à 0.
Je signe tout de suite.
Je ferais même rajouter une clause pour distribuer certaines librairies javascript avec les navigateurs afin que plus jamais elle n'ai besoin de transférer sur le réseau et solutionner un petit plus encore ses problèmes de chargement.
Ceci dit, tu as eu un plus de retours, mais c'est p'tet pas ceux là que tu souhaitais voir pour te motiver, ou autre = )
Encore merci pour le temps que tu as pris à partager ces projets !
a+
# Ah ouais carrément!
Posté par maboiteaspam . En réponse au message Réflexion sur ASM.js ou quand le javascript deviens enfin performant :. Évalué à 4.
hello,
pourquoi ne pas transformer ce post en journal ?
Je me dit que sa visibilité sera bien meilleure et les retours plus nombreux.
Le sujet m’intéresse beaucoup, c'est un peu bas niveau pour moi, mais je sais que j'ai matière à en apprendre.
En plus tu as la plume agréable à lire.
En tout cas j'accroche à ton discours à 200%.
Une approche qui ne casse pas l'existant mais l'améliore, sans dénaturer le JS.
En une phrase, Faudrait être ocn pour passer à côté.
Je surveillerais cela de plus près, merci !
a+
# setup setup, que neni
Posté par maboiteaspam . En réponse au message Site Ecommerce pour TPE/particuliers. Évalué à 1.
Hello,
De mon expérience la partie TPE n'est vraiment pas difficile.
Les banques font des docs très pratique avec en général des exemples à copier, coller, lire attentivement, modifier, déplacer par ftp, et voilà.
Pour ce qui concerne la sécurité, tu seras surtout dépendant de ton prestataire de paiement.
Toutes les solutions que j'ai rencontré sont vigilantes à ce sujet, et t'indiquent les faiblesses de leurs implémentations que tu devras couvrir via quelques configuration bien connues et documentées.
Après à savoir si cela est sécurisé, je ne penses pas, mais le monde s'en contente, alors bon, ce qu'on en dira…
Au sujet de tes solutions e-commerce, je ne sais pas, j'évite comme la peste les usines à gaz qui ne prennent pas mes notes ni ne me font le café.
Partant de là… Mon expérience est trop restreinte.
bref, moi c'est plus l'aspect japonais du site qui m'interroge.
La livraison, le modèle de facture tout cela.
Voir plus simplement, vérifier son travail avec des contenus écris en japonais.
Comme de la perplexité en perspective.
a+
[^] # Re: oui, trois fois
Posté par maboiteaspam . En réponse au sondage Selon vous, pourquoi Linux n'est-il pas prêt pour le bureau ?. Évalué à 0.
Ah beh rien ne force personne à développer sur linux. Et si demain les gens venaient à décider qu'il y à de meilleurs activités dans la vie, il ne s'y prendront pas à deux fois avant de changer de chemin.
Par contre, n'importe quelle société éditrice de logiciel trouvera toujours des gens pour bosser sur ces projets, puisqu'ils sont obligés de payer leurs factures à la fin du mois.
voui. A croire que les dévs apporte plus d'importance à leurs idées d'implémentation plutôt qu'au projet linux dans son entièreté.
Le projet linux devant alors s'adapter aux projets qui le composent plutôt que l'inverse.
N'est ce pas là la difficulté majeure face à un windows ou un mac ?
# oui, trois fois
Posté par maboiteaspam . En réponse au sondage Selon vous, pourquoi Linux n'est-il pas prêt pour le bureau ?. Évalué à -2.
Oui, linux, ou pluot certaines distributions sont prêtes pour le bureau.
Elles savent même se faire aguicheuse.
La dessus, je n'ai pas de doute.
Là où j'ai plus de doutes c'est quand à la capacité de la communauté à maintenir autant de
versions (au sens du numéro, historique)
distro
applications
ET en même temps
arriver à fournir les dernières nouveautés pour l'utilisateur
capitaliser l'existant dans un monde qui change tellement vite
Moi il me semble que le temps perdu à maintenir certaines querelles est vraiment une des raisons qui empêche se projet de s'épanouir plus encore.
Je n'y connais que peu de choses, mais à quoi bon supporter , quoi, 3 4 plus ? boot loader.
lilo, grub, machin, truc et bidule chouette…
Avec à peu près tous le même objectif,
booter un linux, un unix et le reste.
C'est un peu contradictoire comme attitude.
Le libre est par définition en manque de main d'oeuvre, et on s'en rajoute en se disant que c'est plus mieux de maintenir le double de code pour la même fonctionnalité.
Je sais pas…
Enfin, je sais bien que cette diversité est le prix d'une modularité à toute épreuve, c'est ce que je veux croire, mais il me semble que ce n'est pas rationnel pour un sous.
Je sais qu'en tout cas que ces quelques reproches, constats, sont vraiment généralisable dans le monde linux.
[^] # Re: Script simplifié
Posté par maboiteaspam . En réponse au message fuite mémoire PHP. Évalué à 1. Dernière modification le 06 mars 2013 à 11:48.
hello,
j'ai copié coller ton script sur mon apache local ici.
un ps avant
un ps après le premier dl
un ps après plusieurs dl (10aine)
Donc effectivement pas le même constat en fin de compte.
a+
[^] # Re: Forum Programmation.php— fuite mémoirePHP
Posté par maboiteaspam . En réponse au message fuite mémoire PHP. Évalué à 1.
http://php.net/manual/en/features.gc.collecting-cycles.php
Je trouvais ton idée séduisante, mais après lecture de la doc, un peu moins.
# comme ca, je dirais..
Posté par maboiteaspam . En réponse au message fuite mémoire PHP. Évalué à 2.
… Qu'il te manque un coup de flush.
tu fais es echos pour écrire ta donnée sur la sortie standard, mais les 24mo reste dans le buffer d'apache tant que tu n'as pas intimé l'ordre à apache de se vider chez le client.
http://www.php.net/manual/en/function.flush.php
Il précise dans la doc qu'avec mod_gzip activé sur apache, cet appel de flush restera sans effet.
Les commentaires sur php.net, comme souvent, sont précieux de détails divers et variés à consulter obligatoirement.
Autrement, avec le bout de code fournit, je ne vois pas ce qui pourrait bugger. Et n'ayant pas d'expérience de pgsql, je ne saurais connaître ses subtilités.
Dans ta situation, j’essaierais de virer le bruit de mon script pour le focaliser sur un subset du code suffisamment restreint pour tenter d'identifier l'origine du problème.
Dans ton exemple je ferais une version qui ne fais que exécuter / boucler - traiter les résultats de requêtes, sans echo, ni sauvegarde en variable.
Si rien ne se dévoile, alors une autre version avec les echos ect.
Et ainsi de suite.
Finalement, étant donné un numéro de version de php (j'imagine qu'étant sous débian tu ne tournes pas sur la toute dernière version) tu pourrais aussi vérifier les changelogs pour voir si un bug ne semble pas te concerner de près ou de loin,
http://www.php.net/ChangeLog-5.php
il est assez régulier qu'un ou plusieurs leaks soit corrigés.
a+
[^] # Re: en quoi l'interface de gmail justifie l'usage d'un service en ligne ?
Posté par maboiteaspam . En réponse au journal Les vieux cons et le progrès…. Évalué à -1.
On aborde ces nouveautés complètement différemment.
Tu as un point de vue purement utilisateur, et en cela on est d'accord sur à peu près tout ce que tu dis.
A un point près, qui n'a rien à voir avec l'expérience utilisateur,
Ah oui définitivement les technos web n'ont rien inventé. Le principe ajax par exemple c'est faisable en .net ou Qt. Les designs patterns sont les mêmes. Les pratiques de tests et contrôles identiques.
Juste un détail mineur.
Toutes les technos desktop, disons client lourd, sont des tueurs de créativité.
C'est à dire que de part leurs degré de complexité, ces technos sont inaccessible à tout un tas de gens qui ont le besoin, ou le désire, d'écrire une application.
Et ça le HTML, c'est une des raisons de son existence, de son succès. On pensera par ailleurs à php dans la même veine.
C'est le petit détail mineur qui me semble être un killer feature.
Pour le reste, j'ai le sentiment que ce virage, c'est aussi le moment de repensé l'intégration du bureau dans l'écosystème logiciel d'aujourd'hui.
Avant on se fiché d'internet, après on à eu msn, pis vint l'intégration de facebook, twitter ect dans le bureau. Là on en est au moment où le web entre dans le bureau, et pour que ce soit possible, les développeurs webs ont juste besoin d'avoir des spécifications de webservice à suivre.
Hors ce travail là, c'est au développeur de l'OS de le fournir.
C'est du niveau des variables de PATH.
Un problème très concret, j'ai besoin de lancer une instance Java, en mode multiplateforme.
Aujourd'hui pour ce faire, en bash, cela donnes :
pour trouver
un simple chemin d'accès,
d'un exécutable disponible sur 90% des appareils,
et l'exemple ne concerne que le monde linux friendly.
Honnêtement, on peut faire plus simple ?
-- Et je dirais même,
-- on peut faire simple à consommer pour le développeur d'application, et plus libre à développer pour le développeur système.
Bon bah le développeur de demain il à besoin de disposer d'un set de services simples et fonctionnels pour réaliser des tâches communes, récurrentes afin de laisser sa créativité parler.
Plutôt que de perdre son temps à gérer ces querelles d'informaticiens, ou bien encore des détails d'implémentation technique du style "out of memory".
Ces choses qui tuent la créativité instantanément par irradiation mortelle.
J'ai pas bien compris car aujourd’hui si je veux me monter un travis (serveur d'intégration continue) spécifique, je suis obliger de prendre le code, de le descendre et de le setup sur ma machine. De le personnaliser et enfin de le déployer sur une autre machine pour le mettre à dispo de ma communauté.
Demain, j'aurais une signature de webservice pour l'ui.
une définition d'implémentation pour le serveur.
Après, soit le webservice n'est implémenté que de manière fermer, et n'est consommable que via un seul provider.
Soit j'ai à disposition une version libre de son implémentation me permettant de déployer le serveur à ma guise.
Mais dans tous les cas, à minima, mon ui en est indépendante de son implémentation physique et logique, multi device, hébergée en ligne / hors ligne ect ect
bref je peux me brander,
et pour peu que je soit un mec cool, je mets à disposition mon implémentation du serveur pour que chacun puisse le déployer dans son coin.
Bon de toute façon,
le html et ses potes s'imposera.—Notes que, non ce n'est pas un troll, mais que oui, c'est une affirmation sans fondements évident.
Alors après oui on peut continuer à produire des Qt ou des GTK pour faire réaliser certains applications qui aujourd'hui nous semble hors de porter des technos web.
J'ai dans l'idée que ces gens là finiront par améliorer les technos web pour arriver à leurs fins et s'y intégrer, ne serait ce que par un effet mouton de panurge.
a+
PS
Je crois avoir bien dérivé du sujet….
[^] # Re: en quoi l'interface de gmail justifie l'usage d'un service en ligne ?
Posté par maboiteaspam . En réponse au journal Les vieux cons et le progrès…. Évalué à 1. Dernière modification le 23 février 2013 à 06:59.
c'est intéressant cette réflexion du service en ligne / Hors ligne.
Il ne me semblait pas que technos web === en ligne.
Pour moi il devrait y avoir le fournisseur de mail (orange) avec un api, le fournisseur d'UI (MOI! developpeur du dimanche).
Là il y a de la place pour le libre. Chacun pouvant créer son interface.
Après si par ailleurs je n'ai pas les moyens d'héberger mon UI sur des grosses fermes,
Ben figures toi qu'on peut déporter l'hébergement chez le client !
Dingue…. C'est lui qui host l'appli et qui cause en direct avec son fournisseur de mail.
Et en tant que développeur d'UI pour peu que j'ai un installeur capable, qu'est ce qui m’empêche de m'éclater en requiérant un package de bdd nosql et faire mes additifs ?
Le multi plateforme tend à être de plus en plus workable et rien ne m'en empêche.
Découpons, franchement, les applis, ce ne peut pas être si mauvais.
Même si c'est un peu lourd sur certains points…….. on ne peut pas tout avoir, pas tout de suit semble t'il.
[^] # Re: javascript, ok.
Posté par maboiteaspam . En réponse à la dépêche Javascript comme langage par défaut pour GNOME. Évalué à 1.
hello,
je reprends par la fin :°)
et je le coupe en 3
Mon expérience de ces technos est très peu approfondie, un peu de .net, un peu de QT (c'était à l'arrivé de QML mais je n'en ai pas fais à ce moment là), un peu de glade, et après des trucs genre pango (pour les fonts si j'ai bon souvenir).
Bref, oui il y à les tk, qui t'aides beaucoup, mais tu dois encore connecter les events.
Par exemple en QT les signals, ont à priori, extrêmement simplifié le problème, sauf que je me suis battu avec à cause des spécificités de C / C++ eect. (les pointeurs tousssa, Oui j'ai un niveau de m*** en C).
Et puis après il faut effectivement programmer les fonctionnalités. Rebolotte il faut se frotter à tout un tas de concepts qui pour moi sont un vrai problème.
Faudrait que je le testes pour de vrai. Mais je ne peux m’empêcher que cette solution est sous optimale par rapport à une refondation plus profonde comme a pu le faire des projets comme GO ou nodejs (langage que je manipules, mieux que le D, C, c# ect).
Moi je suis très content de ce découplage. Enfin, les technos actuelles purement à base de MVC sont à mon opinion pas bonne du tout.
Mais avec le MVVM pour le client, le MVC pour le serveur tu peux arriver à rendre chacun de ces aspects indépendant, mais pas découplé. J'insiste la dessus, indépendant et non découplé.
Après j'ai l'expérience d'une appli bureau réseau, grosse artillerie, .net Remoting.
Bah je me suis bien amusé au début, après qu'est ce que j'ai ramé……. Je n'ai pas sentit le power to build, mais plutôt le power to debug.
Oui probablement. Mais l'un dans l'autre, les toolkits avec tous les efforts qu'ils ont fait ne sont jamais parvenus à fournir un environnement de développement qui permette à l'industrie non informatique de personnaliser leurs applications bureaux.
Là où le web ne travail qu'à cela depuis 20 ans.
Je ne dis pas qu'ils ne sont pas capable sur le desktop, cela ne s'est pas produit.
Et encore que s'attacher au problème de la beauté de l'ui n'est que le pendant du problème de la gestion multi plateforme.
Dans les deux technos web et desktop le multi plateforme est possible.
Dans les deux technos il y à des plus et des moins.
Je considère que les moins du web sont plus attrayants, plus facile à affronter, que les moins du desktop.
Même des technos comme GO ou nodejs qui sont pourtant toute fraîche et pensée pour aller à l'encontre de ces difficultés ne sont pas encore parvenus à une compatibilité sans défaut sur des concepts identiques.
Pour diverses raisons, ce n'est pas tant la question ici.
Design pattern, pensais tu à autre chose ?
Pour ce qui est de la différence entre mvvm et mvc, j'ai longtemps était dans le flou personnellement. Notamment parce qu'on présente mvvm comme une évolution de mvc cf http://en.wikipedia.org/wiki/MVVM
Alors qu'à mon humble avis ils sont surtout complémentaires et c'est ainsi qu'il faudrait en parler.
Je l'ai compris après avoir builder une application en utilisant knockout.
Éventuellement une bonne vidéo de démo de MVVM à regarder est celle de meteor (recherhe google : meteor js screencast)
bref, le model-view view-model n'intervient que pour synchroniser la vue par rapport au statut d'un modèle de vue (le modele et sa vue dans MVVM).
Car c'est bien d'un modele de Vue dont on parle. Pas d'un modèle de donnée que l'on mets dans un sgbd.
AMHA ce n'est pas un subset, ni une copie identique (penser REST), mais une ré interprétation (on formate, on tri, on prend deux services, on combine et paf un nouveau modèle de vue ect), et une spécialisation (le client de MVVM injecte son état dans son modèle).
Ce client MVVM, discute avec un Controleur de MVC, qui encapsule en entrée / sortie son Modèle de sgbd.
Sa Vue de MVC ne doit "que" formater la réponse en JS / XML / BIN / ce-qu'il-te-plait
Le Contrôleur de MVC, aussi complexe que soit ces règles de gestion, est relativement binaire il répondra toujours succès ou échec. (Les autres trucs 302 404 de HTTP ect c'est pas vraiment son problème à MVC amha, enfin sauf si il décide de ré implémenter une partie de son serveur web lui même… c'est une histoire connue dont je ne parlerais pas)
Le client MVVM peut dès lors consommer ces deux états afin de décider de l'affichage sur sa Vue.
Là où sa devient vraiment beau, c'est à voir l'implémentation de meteor
qui enregistre et applique immédiatement la modification sur son modèle de vue,
envoie sa demande à son contrôleur de MVC côté serveur,
plus tard lorsque le serveur répond, le client MVVM procède alors,
soit à un commit local,
soit un rollback, qui provoque alors une mise à jour de la vue.
Le problème c'est que pour que cela fonctionne bien il faut un pont entre l'implémentation de MVC et MVVM afin de ne pas dupliquer certaines choses comme le routing par exemple.
Il faut qu'il puisse partager des informations. Hors avec des bases en php, asp, java c'est compliqué à moins de passer par des sérialisations, mais alors sa réduit la liberté du développeur.
des réflexions comme sa, à basher, corriger, discuter avec plaisir.
a+
[^] # Re: Meteor
Posté par maboiteaspam . En réponse au journal Écrire une application web de nos jours. Évalué à 1. Dernière modification le 20 février 2013 à 13:15.
Bon je peux plus m'éditer, alors je me parle tout seul, note que je commence à avoir l'habitude ce n'est pas la première fois,
toujours au sujet de meteor, une petite quote qui me plait beaucoup.
Au sujet des modèles stocké dans du sgdbr, http://stackoverflow.com/questions/10605796/meteor-with-mysql
[^] # Re: Meteor
Posté par maboiteaspam . En réponse au journal Écrire une application web de nos jours. Évalué à 1.
Clair!
La vidéo de meteor est absolument géniale.
En plus ils ont vraiment fais les choses bien à mon goût.
C'est simple et direct comme du html, c'est pensé pour faire face aux problèmes de latence, ça produit des livrables indépendants.
Tout simplement mortel.
Et précisément ce que je cherche.
Cependant, et j'ai eu cette réflexion dès qu'ils ont parlé de mongodb, il me semble que c'est difficile de l'intégrer dans un existant avec des sgbdr bien établit et bien remplit.
Le changement d'ui t'imposes de migrer tes données. Ça, c'est pas cool.
En tout cas à part imiter une interface mongodb dans les modèles consommés par météor, je ne vois pas bien comment faire dans l'immédiat.
Mais vraiment bon dans ce premier jet de vidéo.
# Félicitations
Posté par maboiteaspam . En réponse à la dépêche Sortie du noyau Linux 3.8. Évalué à 1.
That's it, that's all.
Félicitations pour cette nouvelle news collaborative !
Allez hop -1 pour futilité, Avec le sourire : )
[^] # Re: bon bah si tout le monde décortiques l'objet, pourquoi pas moi
Posté par maboiteaspam . En réponse à la dépêche Nanoko, un framework JavaScript open source pour applications web & mobiles. Évalué à 2.
mouep par contre il me semble que sa leak à mort votre framework.
Je me suis fais quelques aller retours entre build et philosophy, j'en suis a 7000 nodes… pas terrible
# bon bah si tout le monde décortiques l'objet, pourquoi pas moi
Posté par maboiteaspam . En réponse à la dépêche Nanoko, un framework JavaScript open source pour applications web & mobiles. Évalué à 2. Dernière modification le 19 février 2013 à 13:07.
http://www.nanoko.org/ui/Header.js
En quoi c'est plus simple d'utiliser un descripteur en json plutôt qu'un descripteur en html pour faire ce qui ressemble à un menu dropdown ?
Sinon je préférerais tourner sur une version compilée du site pour sentir mon coeur battre.
Là…. soso. Ça me donne le sentiment d'une usine à gaz qui s'assume pleinement.
Bon après c'est p'tet le cas.
[^] # Re: Qui est choqué ? Le môme ou les parents ?
Posté par maboiteaspam . En réponse au journal [Marc le Bouc] Le contrôle parental ne marche pas :( tristitude snif snif. Évalué à 4. Dernière modification le 19 février 2013 à 12:32.
Clair que le gamin ne peut comprendre la signification.
Mais tout de même c'est un âge formateur pour le cerveau et la mémoire.
Dans le doute des interactions que cela peut avoir, si j'avais un gamin, je préfère m'abstenir.
Un chercheur du cnrs c'est intéressé à l'impact de la télé sur la vie, en général.
Deux points intéressants, amha,
- Aux usa durant leurs scolarité tous les étudiants passe un test. C'est un test pour observer le degré moyen d'intelligence des étudiants. Le fait est, que lorsque la télé est introduite aux usa (j'ai pas la date en tête..), il a été constaté que les résultats de ce test ont instantanément perdu 10 points. *32'22
- la télé agit comme un excitant pour le cerveau qui doit sans cesse faire appel aux mécanismes du réflexe. Hors il se trouve que pour les jeunes enfants cet appel répété soit nocif dans leur apprentissage.
et d'autres trucs intéressants. Sur un coup de folie je colle le lien https://www.youtube.com/watch?v=NvMNf0Po1wY
[^] # Re: pourquoi pertinenter ?
Posté par maboiteaspam . En réponse au message Émission #29 de bloguelinux.ca est disponible. Évalué à 1.
Je n'étais même pas au courant de cette histoire de no follow avec le pr et les pertinantations.
Je dois dire que je serais content d'avoir des posts des éditions diamond ou basta (connais pas celui là) lorsqu'ils sortent une revue.
Après tout c'est l'actualité du libre….
Ne suffirait il pas de créer une catégorie spéciale pour s'arranger de tout ces problèmes de pr ect ?
J'y verrais bien une petite news régulière de misc………
Enfin je ne voulais pas te qualifier de terroriste dans mes propos, il y à eu mésentente, mes excuses les plus plates.
[^] # Re: c'est les parents qu'il faut mettre sous controle
Posté par maboiteaspam . En réponse au journal [Marc le Bouc] Le contrôle parental ne marche pas :( tristitude snif snif. Évalué à 3. Dernière modification le 18 février 2013 à 14:45.
Le meilleur moyens de prendre la grosse tête, s'envoler comme une montgolfière, et de s'écraser la gueule après une longue décente. Mais jusqu'ici tout va bien ; )
[^] # Re: c'est les parents qu'il faut mettre sous controle
Posté par maboiteaspam . En réponse au journal [Marc le Bouc] Le contrôle parental ne marche pas :( tristitude snif snif. Évalué à 2.
C'est le bon peuple m'sieur. Celui qui vote, ont va pas leurs taper dessus si ils ouvrent leurs gueules pour de telles conneries. Qu'ils continuent, au moins ils ne regardent pas la lune.
[^] # Re: c'est les parents qu'il faut mettre sous controle
Posté par maboiteaspam . En réponse au journal [Marc le Bouc] Le contrôle parental ne marche pas :( tristitude snif snif. Évalué à 5.
J'aurais dû être plus précis.
et de s'en plaindre, ils sont stupide ces deux là.
Car après tout chacun fait ce qu'il veut de l'éducation de ces gamins.
C'est surtout qu'ils s'en étonnent que je trouve stupide, la légende d'une des photos, "Devant son ordinateur Alexandre de franca n'en revient toujours pas".
Mais !!! c'est tellement stupide comme attitude que même le commentaire en est d'une niaiserie pathétique..
# c'est les parents qu'il faut mettre sous controle
Posté par maboiteaspam . En réponse au journal [Marc le Bouc] Le contrôle parental ne marche pas :( tristitude snif snif. Évalué à 10.
laisser internet dans les mains d'un gamins de deux ans, ils sont stupide ces deux là.