Très intéressant merci.
Mais comme tu l'évoques la presque totalité des langages utilisent une construction de ce genre plutôt que l'autre qui n'est pas plus courte.
Point point = new Point(1.2, -3.7);
ou encore
point=Point(x=1.2, y=-3.7)
mais Perl invente un .= dont on ne comprend pas bien à quoi il s'applique et 2 codeurs différents utiliseront l'une ou l'autre des synatxes.
Perso, je préfère investir mon temps à comprendre l'algorithme plutôt que la syntaxe.
C'est juste la technique gouvernementale habituelle.
On balance un paquet de mesure plus ou moins acceptable avec une trop grosse pour passer (l'amende pour non securisation).
Tout le monde va se focaliser là dessus, s'indigner et le reste passera comme une lettre à la poste. L'affaire est jouée !
Ceci n'a rien a voir un uniligne , ce n'est juste qu'un extrait symptomatique d'un code complet.
La preuve, ton collègue plus haut affirme même le contraire de toi. C'est du code purement perlien de quelqu'un qui maitrise les concepts de base du langage et les utilise: je lui accorde.
Evidemment, avec TIMTOWTDI difficile d'imposer un style commun à un équipe et encore plus, de ne pas se contredire sur un forum.
Il y a
- ceux qui disent qu'il faut commenter
- ceux qui disent que c'est assez expressif et qu'il ne faut pas coder à la "C"
- ceux qui disent comme toi qu'un bon code perl est possible si on nomme correctement les variables, qu'on utilise des constructions explicite à la "C" (quoique le C ne soit pas une référence)
C'est quand même mieux quand le langage est prévisible.
Sinon le pauvre d'esprit te remercie.
Si je voulais rester dans la tradition religieuse LarryWallienne je répondrais:
"Heureux les simples d'esprit, le royaume des cieux leur appartient"
Sinon merci pour ce lien très intéressant qui me rappelle une autre des caractéristique de perl.
Une syntaxe tellement "riche" qui fait qu'on démultiplie les opérateurs pour désambiguer des opérations.
Ici on a
my Point $point .= new( :x<1.2>, :y<-3.7> );
Pourquoi ".=" et pas "="
alors que 2 ligne plus l'affectation est bien un =
$point.x = 2;
C'est la concaténation de chaine (avec quoi d'ailleurs) , c'est l'opérateur d'affectation pour les références d'objet ?
Pour le savoir il va falloir se replonger dans la doc (ca fait 3 ans que je ne pratique plus le Perl)
Ca me rappelle même qu'à l'époque, même mon emacs abdiquait sur certains scripts. Il n'était plus capable de les parser tellement la grammaire du langage doit être simple.
Oh! mais rassures toi, je comprend cette ligne parfaitement puisque j'ai eu a maintenir ce code .
Et j'ai pu comparer la courbe d'apprentissage et le ROI du langage avec celle d'autres pour m'en faire une idée et l'éviter autant que faire se peut à l'avenir.
C'est juste parce qu'elle est assez significative que je l'ai montrée.
Le gars qui a pondu ce truc est un cador perl depuis 15 ans et il utilise tous les artifices.
Mais comme il est pressé, on l'est tjs dans une boîte, ben il ne met surtout pas de commentaire.
Ce beau langage qui cumule plein de bonnes idées:
- On a d'abord le contexte avec des jolis signes cabalistiques tellement expressifs genre @_.
Comme ca si tu insères du code, tu te retrouves avec des effets de bord imprévus. Ils ont enfin résolu le grand dilemme de l'informatique: La stabilité. Plus personne n'ose le retoucher le code.
-Tu as aussi comme tu l'évoques toutes ces belles fonctions comme "lc" ,volontairement sibyllines pour gagner du temps de frappe. Le perl en est tellement rempli que le docperl leur vaut un procès avec "le Petit Larousse illustré" pour concurrence déloyale. Tu perds plus de temps à fouiner dans cette doc pour trouver ce que tu cherches qu'à produire 1 ligne de code. Après le phénomène d'engagement ( http://fr.wikipedia.org/wiki/Th%C3%A9orie_de_l%27engagement ) fait le reste: Perl c'est trop trop bien !
- De même, cette bonne idée d'utiliser des signes pour interpréter la valeur d'une variable nous vient du fait que Perl est un langage faiblement typé. Ce qui rend les tableaux à 2 dimensions de référence à des fonctions tellement évidents à utiliser. Quel pied lorsque tu as enfin trouvé la bonne combinaison pour aller chercher la bonne valeur d'indice ou la bonne clé d'indirection après 2 heures de lutte acharnée. Faut surtout pas t'arrêter là parce qu'à la différence du vélo, ca s'oublie vite. Perl, ca se mérite !
Autre effet intéressant, les cast implicites qui t'octroient le plaisir jouissif de debugguer des heures un effet de bord avec en plus la religiosité absolue de relire l'intégrale de Larry Wall.
- Tu as aussi les opérateurs à la pelle (Ben oui, ils ont épuisé toutes les combinaisons à 2 lettres de l'alphabet latin, faut bien étendre un peu. A quand l'alphabet elfique ou Sauronique ?)
En plus quand ca ne t'arrange parce que tu as tout épuisé comme lettre dans ta regexp, tu peux changer de délimiteurs. Au lieu des // et utiliser par exemple un ~ ~.
C'est tellement joli ces onomatopées qui rappellent les injures censurées dans les BDs
- On pourrait aussi parler de l'aplanissement des listes juste pour se démarquer des autres ou encore de la bénédiction des objets qui renvoie les pythoneux et leur Monty au rang de plébéiens du clavier.
...
En voilà un langage , qui ne cumule définitivement que des bon points:
Il réussit le tour de force d'être à la fois élitiste, laid et illisible.
Mais tu es mieux placé et peut-être que tu dis vrai.
Le support est payant et sûrement dissuasif, mais tu peux peut-être nous communiquer les tarifs.
En cumulant avec tous les clients qui payent on doit largement couvrir les frais de maintenance
Avec un tel budget, peut-être qu'une SSLL serait prête à prendre en charge le support d'une distrib.
Il faut donc comparer, ce qui est comparable.
Il y a n distrib linux avec des parts de marché cumulées infimes par rapport à W$.
Si ca devenait rentable, nul doute que tu aurais ton exemple.
Le pragmatisme, les entreprises non philanthropes, ... ce sont des chose qui te sont familières en général.
Bref, le fait qu'il n'y ait pas d'exemple n'implique pas que ce ne soit pas faisable.
Et y a t'il seulement eu une demande client de ce type d'ailleurs ?
Une SSLL ne va pas proposer un service qui n'intéresse personne.
Ah bon Gmail n'est pas compatible IMAP ?
Tu ne peux pas non plus exporter tes bookmarks de del.icio.us, ni les synchroniser avec ton FF ?
Facebook , je connais pas.
C'est comme tout, tu as du bon et du mauvais dans le web2.0.
Le problème est de trier le bon grain de l'ivraie.
Mais il n'y a pas de panacée, mon cher, en matière de parallélisme. Quelque soit la technique utilisée, c'est toujours beaucoup plus délicat de faire du code parallèle que du code strictement séquentiel, car il faut maîtriser tous les problèmes de synchronisation qui surgissent.
Ironiquement, quand on veut faire de la programmation multi-thread robuste, on en arrive souvent à utiliser les mêmes techniques que pour du multi-processing : par exemple du passage de messages.
Marrant , je vois déjà un intérêt dans le multithreading: les IHMs.
Je trouve relativement naturel de lancer un ou plusieurs traitements long en tâche de fond sans bloquer l'utilisateur.
C'est relativement simple en lancant un thread par traitement.
Avec du multiprocess tu dois lancer un nouveau process avec tout la batterie d'artifices qui s'ensuit, si tu dois mettre en place des mécanismes de synchro. Mais tu as raison, on peut s'en sortir, au prix de quels sacrifices.
Et après, ca vient donner des leçon de simplicité aux utilisateurs de langages statiquement typés.
Ah oui mais python supporte le multithreading ...séquentiel, j'allais oublier.
Et en plus il tourne sur plein de vm qui supporte le multithread.
Bon, l'important c'est que tu admettes que l'étude de Dave est intéressante.
Ca permettra peut-être de convaincre le dictateur éclairé de revoir sa position.
A l'heure où le multi coeur s'impose, juste pour les midinettes pas parce qu'on atteint des limites techniques en terme de miniaturisation, Python, degrade encore plus les performances que sur un mono-coeur.
Tu as raison c'est seulement un des aspects de la performance.
Et il vrai que le multiprocess est la panacée lorsque tu dois refactorer ton code.
Expliquez moi ce dont vous avez besoin, je vous expliquerai comment vous en passer.
probablement pas le plus important pour ce à quoi est utilisé Python généralement.
C'est pas les pythonista qui affirment que python n'est pas qu'un langage de script et qu'on peut tout faire avec.
Il y a un navigateur web intégré... mais, bon sang, à quoi cela peut-il bien servir ?
A ouvrir la page Wikipédia de l'artiste.
IN-CON-TOUR-NABLE, kizondi !
1/ Pour les windowsiens, Windows Media Player est moins lourd et iTunes existe déjà, pas la peine de le copier
Si ! Il existe un clonedérivé libre qui s'assume et qui n'utilise pas XUL&Co
Bref ! un truc qui fait ce qu'on lui demande http://www.atunes.org/
MusikCube n'évolue plus depuis longtemps et quitte à faire, si vraiment tu y tiens, prend l'original qui était vraiment multi-plateforme http://musik.berlios.de/?id=home
C'est pas assez concret ?
Pourtant ca vient d'un monsieur qui n'est pas réputé pour être un détracteur de python. http://www.dabeaz.com/
Mais comme Guido a dit que le multithreading ne servait à rien et que le multiprocess faisait bien l'affaire.
Je replace les conclusions pour montrer comme ca n'a qu'un impact mineur
Is it Worth It?
• If you could fix it, it would make thread
execution (even with the GIL) more
predictable and less resource intensive
• Might improve performance/responsiveness of
applications that have a mix of CPU and I/Obound
processing
• Probably good for libraries that use threads in
the background (e.g., multiprocessing)
• Might be able to do it without rewriting the
whole interpreter.
Ils n'hébergent pas les données, juste l'interface. Par contre, ils peuvent certainement loguer qui télécharge quoi chez qui.
C'est pas ce que j'ai dit ?
Ils utilisent le réseau social de my.opera.com pour te proposer les "Unites" de tes amis quand tu navigues sur le tien, c'est un réseau social. L'application principal est de partager des fichiers et des informations (post-its, salon de discussion). J'appelle ça un réseau social de partage.
L'auto-hébergement, c'est bien quand tu maitrises tes données.
Ici on doit faire confiance à un tiers puisqu'on ne dispose pas des sources et que semble t'il d'après un commentaire plus bas, l'IHM est déporté chez Opera.
puisqu'il faut un compte opera et que l'interface est hébergée sur les serveurs
Tu veux dire qu'au lieu d'un SPOF, on en a deux.
En plus comme c'est pas libre, il faut leur faire confiance sur le fait qu'il n'utilisent pas les données que tu héberges (pas mieux que Google en fait). D'ailleurs je n'ai pas trouvé de précision sur "Unité" dans leur section privacy.
Je ne vois toujours pas l'avantage par rapport un service hosté d'autant qu'on ne peut pas profiter de tous l'aspect collaboratif qui fait la vraie valeur du web 2.0.: L'information mutuellement enrichie.
Est-ce qu'ils proposeront un moteur de recherche ou bien cela restera-t-il un réseau social de partage, la question se pose.
Sauf que je ne vois pas l'intérêt de le coupler à un navigateur.
D'ailleurs, il semble qu'il soit distribué en standalone ce qui semble contredire le contenu du journal
Bref on a juste un serveur web maison facile à installer avec quelques services préinstallés.
Je maintiens, rien de révolutionnaire mais je peux me tromper.
Ce qui serait révolutionnaire, ca serait de pouvoir décider quelles données peuvent être partagées entre différentes instances de serveurs qui collaborent (genre des tags sur des urls bookmarkées, des photos avec leur tag, ...)
[^] # Re: Performances
Posté par Bozo_le_clown . En réponse à la dépêche Sortie d'Eclipse 3.5 - Galileo. Évalué à 2.
[^] # Re: Analyse poussée ?
Posté par Bozo_le_clown . En réponse au journal Raisons pour qu'un État n'investisse pas dans le logiciel libre. Évalué à 2.
Mais comme tu l'évoques la presque totalité des langages utilisent une construction de ce genre plutôt que l'autre qui n'est pas plus courte.
Point point = new Point(1.2, -3.7);
ou encore
point=Point(x=1.2, y=-3.7)
mais Perl invente un .= dont on ne comprend pas bien à quoi il s'applique et 2 codeurs différents utiliseront l'une ou l'autre des synatxes.
Perso, je préfère investir mon temps à comprendre l'algorithme plutôt que la syntaxe.
# Esbrouffe !!!
Posté par Bozo_le_clown . En réponse au journal Hadopi contre attaque. Évalué à 10.
On balance un paquet de mesure plus ou moins acceptable avec une trop grosse pour passer (l'amende pour non securisation).
Tout le monde va se focaliser là dessus, s'indigner et le reste passera comme une lettre à la poste. L'affaire est jouée !
[^] # Re: Analyse poussée ?
Posté par Bozo_le_clown . En réponse au journal Raisons pour qu'un État n'investisse pas dans le logiciel libre. Évalué à 2.
La preuve, ton collègue plus haut affirme même le contraire de toi. C'est du code purement perlien de quelqu'un qui maitrise les concepts de base du langage et les utilise: je lui accorde.
Evidemment, avec TIMTOWTDI difficile d'imposer un style commun à un équipe et encore plus, de ne pas se contredire sur un forum.
Il y a
- ceux qui disent qu'il faut commenter
- ceux qui disent que c'est assez expressif et qu'il ne faut pas coder à la "C"
- ceux qui disent comme toi qu'un bon code perl est possible si on nomme correctement les variables, qu'on utilise des constructions explicite à la "C" (quoique le C ne soit pas une référence)
C'est quand même mieux quand le langage est prévisible.
Sinon le pauvre d'esprit te remercie.
Si je voulais rester dans la tradition religieuse LarryWallienne je répondrais:
"Heureux les simples d'esprit, le royaume des cieux leur appartient"
[^] # Re: Analyse poussée ?
Posté par Bozo_le_clown . En réponse au journal Raisons pour qu'un État n'investisse pas dans le logiciel libre. Évalué à 2.
Une syntaxe tellement "riche" qui fait qu'on démultiplie les opérateurs pour désambiguer des opérations.
Ici on a
my Point $point .= new( :x<1.2>, :y<-3.7> );
Pourquoi ".=" et pas "="
alors que 2 ligne plus l'affectation est bien un =
$point.x = 2;
C'est la concaténation de chaine (avec quoi d'ailleurs) , c'est l'opérateur d'affectation pour les références d'objet ?
Pour le savoir il va falloir se replonger dans la doc (ca fait 3 ans que je ne pratique plus le Perl)
Ca me rappelle même qu'à l'époque, même mon emacs abdiquait sur certains scripts. Il n'était plus capable de les parser tellement la grammaire du langage doit être simple.
[^] # Re: Analyse poussée ?
Posté par Bozo_le_clown . En réponse au journal Raisons pour qu'un État n'investisse pas dans le logiciel libre. Évalué à 2.
Et j'ai pu comparer la courbe d'apprentissage et le ROI du langage avec celle d'autres pour m'en faire une idée et l'éviter autant que faire se peut à l'avenir.
C'est juste parce qu'elle est assez significative que je l'ai montrée.
[^] # Re: Analyse poussée ?
Posté par Bozo_le_clown . En réponse au journal Raisons pour qu'un État n'investisse pas dans le logiciel libre. Évalué à 4.
Le gars qui a pondu ce truc est un cador perl depuis 15 ans et il utilise tous les artifices.
Mais comme il est pressé, on l'est tjs dans une boîte, ben il ne met surtout pas de commentaire.
Ce beau langage qui cumule plein de bonnes idées:
- On a d'abord le contexte avec des jolis signes cabalistiques tellement expressifs genre @_.
Comme ca si tu insères du code, tu te retrouves avec des effets de bord imprévus. Ils ont enfin résolu le grand dilemme de l'informatique: La stabilité. Plus personne n'ose le retoucher le code.
-Tu as aussi comme tu l'évoques toutes ces belles fonctions comme "lc" ,volontairement sibyllines pour gagner du temps de frappe. Le perl en est tellement rempli que le docperl leur vaut un procès avec "le Petit Larousse illustré" pour concurrence déloyale. Tu perds plus de temps à fouiner dans cette doc pour trouver ce que tu cherches qu'à produire 1 ligne de code. Après le phénomène d'engagement ( http://fr.wikipedia.org/wiki/Th%C3%A9orie_de_l%27engagement ) fait le reste: Perl c'est trop trop bien !
- De même, cette bonne idée d'utiliser des signes pour interpréter la valeur d'une variable nous vient du fait que Perl est un langage faiblement typé. Ce qui rend les tableaux à 2 dimensions de référence à des fonctions tellement évidents à utiliser. Quel pied lorsque tu as enfin trouvé la bonne combinaison pour aller chercher la bonne valeur d'indice ou la bonne clé d'indirection après 2 heures de lutte acharnée. Faut surtout pas t'arrêter là parce qu'à la différence du vélo, ca s'oublie vite. Perl, ca se mérite !
Autre effet intéressant, les cast implicites qui t'octroient le plaisir jouissif de debugguer des heures un effet de bord avec en plus la religiosité absolue de relire l'intégrale de Larry Wall.
- Tu as aussi les opérateurs à la pelle (Ben oui, ils ont épuisé toutes les combinaisons à 2 lettres de l'alphabet latin, faut bien étendre un peu. A quand l'alphabet elfique ou Sauronique ?)
En plus quand ca ne t'arrange parce que tu as tout épuisé comme lettre dans ta regexp, tu peux changer de délimiteurs. Au lieu des // et utiliser par exemple un ~ ~.
C'est tellement joli ces onomatopées qui rappellent les injures censurées dans les BDs
- On pourrait aussi parler de l'aplanissement des listes juste pour se démarquer des autres ou encore de la bénédiction des objets qui renvoie les pythoneux et leur Monty au rang de plébéiens du clavier.
...
En voilà un langage , qui ne cumule définitivement que des bon points:
Il réussit le tour de force d'être à la fois élitiste, laid et illisible.
[^] # Re: du flou...
Posté par Bozo_le_clown . En réponse au journal Au coeur de la cyberguerre. Évalué à 2.
Le support étendu est de 2 ans.
http://www.01net.com/editorial/307002/poste-de-travail/le-su(...)
Pour NT4 ca a donc dù s'arreter en 2007
http://www.zdnet.fr/actualites/informatique/0,39040745,39197(...)
Mais tu es mieux placé et peut-être que tu dis vrai.
Le support est payant et sûrement dissuasif, mais tu peux peut-être nous communiquer les tarifs.
En cumulant avec tous les clients qui payent on doit largement couvrir les frais de maintenance
Avec un tel budget, peut-être qu'une SSLL serait prête à prendre en charge le support d'une distrib.
Il faut donc comparer, ce qui est comparable.
Il y a n distrib linux avec des parts de marché cumulées infimes par rapport à W$.
Si ca devenait rentable, nul doute que tu aurais ton exemple.
Le pragmatisme, les entreprises non philanthropes, ... ce sont des chose qui te sont familières en général.
Bref, le fait qu'il n'y ait pas d'exemple n'implique pas que ce ne soit pas faisable.
Et y a t'il seulement eu une demande client de ce type d'ailleurs ?
Une SSLL ne va pas proposer un service qui n'intéresse personne.
[^] # Re: du flou...
Posté par Bozo_le_clown . En réponse au journal Au coeur de la cyberguerre. Évalué à 7.
Quoique la même question s'applique aussi à XP et Vista d'ailleurs.
[^] # Re: Analyse poussée ?
Posté par Bozo_le_clown . En réponse au journal Raisons pour qu'un État n'investisse pas dans le logiciel libre. Évalué à 1.
illisible c'est ca:
/^((Lb|Br)Type) \d+(:.+)$/ and push @types,lc($1) . $3 . "\@$var";
[^] # Re: minitel 2.0 ?
Posté par Bozo_le_clown . En réponse au journal De la sécurité des informations personnelles sur Internet. Évalué à 2.
Tu ne peux pas non plus exporter tes bookmarks de del.icio.us, ni les synchroniser avec ton FF ?
Facebook , je connais pas.
C'est comme tout, tu as du bon et du mauvais dans le web2.0.
Le problème est de trier le bon grain de l'ivraie.
[^] # Re: Analyse poussée ?
Posté par Bozo_le_clown . En réponse au journal Raisons pour qu'un État n'investisse pas dans le logiciel libre. Évalué à 0.
[^] # Re: Ça passe très bien :)
Posté par Bozo_le_clown . En réponse à la dépêche Jython supporte maintenant Python 2.5. Évalué à 3.
Mais il n'y a pas de panacée, mon cher, en matière de parallélisme. Quelque soit la technique utilisée, c'est toujours beaucoup plus délicat de faire du code parallèle que du code strictement séquentiel, car il faut maîtriser tous les problèmes de synchronisation qui surgissent.
Ironiquement, quand on veut faire de la programmation multi-thread robuste, on en arrive souvent à utiliser les mêmes techniques que pour du multi-processing : par exemple du passage de messages.
Marrant , je vois déjà un intérêt dans le multithreading: les IHMs.
Je trouve relativement naturel de lancer un ou plusieurs traitements long en tâche de fond sans bloquer l'utilisateur.
C'est relativement simple en lancant un thread par traitement.
Avec du multiprocess tu dois lancer un nouveau process avec tout la batterie d'artifices qui s'ensuit, si tu dois mettre en place des mécanismes de synchro. Mais tu as raison, on peut s'en sortir, au prix de quels sacrifices.
Et après, ca vient donner des leçon de simplicité aux utilisateurs de langages statiquement typés.
Ah oui mais python supporte le multithreading ...séquentiel, j'allais oublier.
Et en plus il tourne sur plein de vm qui supporte le multithread.
Bon, l'important c'est que tu admettes que l'étude de Dave est intéressante.
Ca permettra peut-être de convaincre le dictateur éclairé de revoir sa position.
[^] # Re: Analyse poussée ?
Posté par Bozo_le_clown . En réponse au journal Raisons pour qu'un État n'investisse pas dans le logiciel libre. Évalué à 2.
http://www.cio-online.com/actualites/lire-europeennes-l-ump-(...)
[^] # Re: Ça passe très bien :)
Posté par Bozo_le_clown . En réponse à la dépêche Jython supporte maintenant Python 2.5. Évalué à 2.
Tu as raison c'est seulement un des aspects de la performance.
Et il vrai que le multiprocess est la panacée lorsque tu dois refactorer ton code.
Expliquez moi ce dont vous avez besoin, je vous expliquerai comment vous en passer.
probablement pas le plus important pour ce à quoi est utilisé Python généralement.
C'est pas les pythonista qui affirment que python n'est pas qu'un langage de script et qu'on peut tout faire avec.
[^] # Re: Bloat, quand tu nous tiens...
Posté par Bozo_le_clown . En réponse à la dépêche Sortie de Songbird 1.2. Évalué à 2.
Il y a un navigateur web intégré... mais, bon sang, à quoi cela peut-il bien servir ?
A ouvrir la page Wikipédia de l'artiste.
IN-CON-TOUR-NABLE, kizondi !
1/ Pour les windowsiens, Windows Media Player est moins lourd et iTunes existe déjà, pas la peine de le copier
Si ! Il existe un clonedérivé libre qui s'assume et qui n'utilise pas XUL&Co
Bref ! un truc qui fait ce qu'on lui demande
http://www.atunes.org/
MusikCube n'évolue plus depuis longtemps et quitte à faire, si vraiment tu y tiens, prend l'original qui était vraiment multi-plateforme
http://musik.berlios.de/?id=home
[^] # Re: Ça passe très bien :)
Posté par Bozo_le_clown . En réponse à la dépêche Jython supporte maintenant Python 2.5. Évalué à 1.
C'est pas assez concret ?
Pourtant ca vient d'un monsieur qui n'est pas réputé pour être un détracteur de python.
http://www.dabeaz.com/
Mais comme Guido a dit que le multithreading ne servait à rien et que le multiprocess faisait bien l'affaire.
Je replace les conclusions pour montrer comme ca n'a qu'un impact mineur
Is it Worth It?
• If you could fix it, it would make thread
execution (even with the GIL) more
predictable and less resource intensive
• Might improve performance/responsiveness of
applications that have a mix of CPU and I/Obound
processing
• Probably good for libraries that use threads in
the background (e.g., multiprocessing)
• Might be able to do it without rewriting the
whole interpreter.
[^] # Re: Attention on vous surveille
Posté par Bozo_le_clown . En réponse à la dépêche Sortie de Songbird 1.2. Évalué à 3.
[^] # Re: pinaise
Posté par Bozo_le_clown . En réponse au journal Une virgule manque, et l'entreprise peut s'effondrer !. Évalué à 2.
[^] # Re: Ah ah ! Trop gros ça ne passera pas !
Posté par Bozo_le_clown . En réponse à la dépêche Jython supporte maintenant Python 2.5. Évalué à 1.
# Levure
Posté par Bozo_le_clown . En réponse au journal Le pain. Évalué à 3.
[^] # Re: Intéressant
Posté par Bozo_le_clown . En réponse au journal Opéra mélange serveur et client web. Évalué à 2.
Ils n'hébergent pas les données, juste l'interface. Par contre, ils peuvent certainement loguer qui télécharge quoi chez qui.
C'est pas ce que j'ai dit ?
Ils utilisent le réseau social de my.opera.com pour te proposer les "Unites" de tes amis quand tu navigues sur le tien, c'est un réseau social. L'application principal est de partager des fichiers et des informations (post-its, salon de discussion). J'appelle ça un réseau social de partage.
Ceci est intéressant.
J'y jetterai un coup d'oeil
[^] # Re: Minitel 2.0
Posté par Bozo_le_clown . En réponse au journal Opéra mélange serveur et client web. Évalué à 3.
Ici on doit faire confiance à un tiers puisqu'on ne dispose pas des sources et que semble t'il d'après un commentaire plus bas, l'IHM est déporté chez Opera.
[^] # Re: Intéressant
Posté par Bozo_le_clown . En réponse au journal Opéra mélange serveur et client web. Évalué à 1.
puisqu'il faut un compte opera et que l'interface est hébergée sur les serveurs
Tu veux dire qu'au lieu d'un SPOF, on en a deux.
En plus comme c'est pas libre, il faut leur faire confiance sur le fait qu'il n'utilisent pas les données que tu héberges (pas mieux que Google en fait). D'ailleurs je n'ai pas trouvé de précision sur "Unité" dans leur section privacy.
Je ne vois toujours pas l'avantage par rapport un service hosté d'autant qu'on ne peut pas profiter de tous l'aspect collaboratif qui fait la vraie valeur du web 2.0.: L'information mutuellement enrichie.
Est-ce qu'ils proposeront un moteur de recherche ou bien cela restera-t-il un réseau social de partage, la question se pose.
Ce n'est pas un réseau social de partage
[^] # Re: pas sur que ce soit "innovant"
Posté par Bozo_le_clown . En réponse au journal Opéra mélange serveur et client web. Évalué à 2.
D'ailleurs, il semble qu'il soit distribué en standalone ce qui semble contredire le contenu du journal
Bref on a juste un serveur web maison facile à installer avec quelques services préinstallés.
Je maintiens, rien de révolutionnaire mais je peux me tromper.
Ce qui serait révolutionnaire, ca serait de pouvoir décider quelles données peuvent être partagées entre différentes instances de serveurs qui collaborent (genre des tags sur des urls bookmarkées, des photos avec leur tag, ...)