wilk a écrit 1159 commentaires

Une interview de Jeremy Rifkin où il fait l'analogie avec linux, wikipédia…

video http://www.youtube.com/watch?v=4m3Mis9vIX0
texte http://www.agoravox.tv/actualites/societe/article/le-nucleaire-est-mort-vive-jeremy-30459

…
Le pouvoir latéral de millions et de millions de petits acteurs qui partagent cette énergie latéralement, cela écrase tout ce que vous pouviez faire avec le nucléaire. Tout comme des millions de personne qui ont une bonne connaissance de la technologie, qui se connectent sur des ordinateurs personnels, l’énergie distribuée dépasse tout ce qu’un ordinateur centralisé peut faire.
…
Quatre générations qui grandissent avec internet, capables de créer leurs propres informations et de les partager dans des lieux ouverts et communs. Vous pensez vraiment qu’ils vont être entourés par des centrales nucléaires démodées, peu sûres, du 20ème siècle, centralisées, hiérarchisées.
…

On peut traiter le champ json avec les langages, dont javascript V8 : http://code.google.com/p/plv8js/
J'imagine qu'il y en aura s'il y a un besoin. Il y en a déjà deux array_to_json et row_to_json.

http://www.postgresql.org/docs/devel/static/functions-json.html

Il semble que postgresql intègre de plus en plus les particularités des nosql.
réplication, parcours des index seuls, champ json, unlogged table…

Un journal vient d'être publié à ce sujet http://linuxfr.org/users/arthurr/journaux/postgresql-9-2-beta-1

Encore plus libre, on peut facilement étudier son fonctionnement, le modifier, le partager, l'utiliser comme on le souhaite… Mais le vélo, c'est mieux sans les voitures autour http://carfree.fr

Au contraire, c'est beaucoup plus simple. La c'est un vrai casse tête de PMU, voter utile ou pas ? qu'est-ce qui est utile ?

Un pull n'est pas récursif car ça n'est pas son but, tout comme un pull ne fait pas un update d'office. Je trouve normal que ça ne soit pas par défaut. Après que ce soit possible par une extension ou une option, pourquoi pas.
Personnellement, quand je veux systématiquement la dernière version d'un sous-projet (une lib), j'utilise un lien. Quand je veux avoir une version bien particulière j'utilise un subrepos.

Si j'ai bien compris ton sub-repo a bien les changements mais si tu ne fais pas d'update tu ne travailleras pas dessus, c'est valable avec n'importe quel push, subrepo ou pas.

A noter la nouvelle fonctionnalité de mercurial : les phases, qui permettent d'avoir des changesets "secrets" tant qu'ils ne sont pas publiés, et donc de faire du rebase dessus sans danger (si j'ai bien compris car je n'ai pas encore essayé).

http://www.logilab.org/blogentry/88203

Si on ne réinventait pas la roue de temps en temps on aurait des roues en bois sur les vélos ;-)

• il est difficile de rentrer dans le code de PyPy (touffu, très peu documenté ni commenté, y compris RPython lui-même)
• le système de build peut rendre fou (traduire l'interpréteur en code natif prend 30 à 60 minutes, et il n'y a pas de traduction incrémentale)

Ce sont ces points qui mériteraient un appel au don car ils ne seront jamais faits gratuitement contrairement à des choses plus motivantes... Ca rendrait pypy plus pérenne, les boites qui l'utilisent aujourd'hui y seraient sûrement sensibles.

D'un autre côté, plus les releases sont fréquentes moins il y a de boulot à faire lors des upgrades...

C'est surtout les ABI-tudes des utilisateurs qui ne respectent pas la compatibilité ascendante !

C'est quitte ou double. Le risque c'est qu'un langage qui n'évolue plus sera moins sujet à être maintenu qu'un langage qui évolue. C'est une histoire d'équilibre, un langage qui évolue lentement et donc facile à suivre ou un langage qui n'évolue plus et qui risque de devenir obsolète brutalement.

Pour pypy, la question est posée de supporter à la fois la 2 et la 3 sur la même base de code.

http://pypy.org/py3donate.html

Planned stages of work

The goal of this project is to write an interpreter that interprets version 3 of the Python language. To be precise we would aim at having a Python 3.2 interpreter together in the same codebase as the python 2.7 one.

At the end of the project, it will be possible to decide at translation time whether to build an interpreter which supports Python 2.7 or Python 3.2 and both versions will be nightly tested and available from nightly builds.

Python en lui-même n'a aucune date de péremption, c'est un logiciel libre, tu as les sources, qu'est-ce qui pourrait t'empêcher de le faire tourner, lui et les applis développées avec, dans 50 ans ? Si quelque chose t'en empêche ce sera les composants du système, les librairies en C qu'il utilise etc. Mais pas le langage lui-même.

Pour ce qui est du courage des développeurs pour suivre les upgrades du langage, rassure toi c'est trivial dans la grande majorité des cas. Surtout, c'est ridicule par rapport aux problèmes de compatibilités extérieurs (libs, système, bdd, utilisateurs...)

Je suis tout à fait d'accord, tout ce que l'on peut vérifier automatiquement est toujours bénéfique, si j'ai bien compris dialyzer est un peu l'équivalent de pylint ?
Je n'apprécie pas quand c'est au détriment de la lisibilité du code ou que cela m'empêche de profiter du côté dynamique du langage. Pour revenir au langage idéal, qu'il devine tout seul les erreurs de type quand il le peu et ce sera très bien mais qu'il ne m'oblige pas à lui mâcher le travail. Je ne me plaint pas que python sache vérifier la syntaxe avant l'exécution (j'utilise vimflakes par ex).

Je n'ai pas d'historique de code qui me vient comme ça à montrer (je ne fais que du dev spécifique), mais j'ai regardé, honnêtement j'ai quelques cas d'erreurs de types qui reviennent, string/unicode et float/Decimal. Mais même dans ces cas bien souvent le compilateur n'aurait rien vu car les données arrivent d'un sgbd...

Pour ce qui est de projets réels, professionnellement je suis passé par C et Java avant Python, et au début je n'y croyait pas non plus, mais maintenant, sur plusieurs années, sur parfois des programmes exactement identiques (réécrits), le temps de maintenance est drastiquement réduit. Pour mon usage c'est le langage idéal.

Par contre si ce n'était pas pour le boulot et donc des contraintes de rendement, je préfèrerai le C pour son côté plus proche du système.

GLMF ce n'est pas une secte ou un parti politique, c'est un ensemble de personnes qui écrivent sur ce qu'ils font avec GNU/Linux.

En l'occurrence ils se mettent à dire ce qu'ils ne font plus avec GNU/Linux !

Python est d’une lenteur effroyable…

Tu as essayé pypy ?

Sur un algo de calcul d'itinéraires j'ai un gain d'un facteur 10 !

Un système de typage statique réaliste ne capturera pas tous les invariants de ton programme, mais ce n'est pas une raison pour les rejeter en bloc, s'il peut déjà capturer les invariants "faciles" et te laisser raisonner sans aide, ou vérifier dynamiquement, les autres, c'est déjà ça.

Sauf que les invariants "faciles", ceux qui sont détectés à notre place, sont rarement ceux qui posent problème. Du reste c'est plus pour aider le compilateur que le développeur, sinon on obligerait à nommer les arguments en appel de fonction par exemple c'est une erreur beaucoup plus commune et qui passe tranquillement la compilation.

Par ex ma_fonction(int a, int b), si on inverse a et b le compilateur n'y verra rien. Si a est censé être plus petit que b il n'y verra rien non plus. En python si on applique la règle d'être explicite on écrira ma_fonction(plus_petit, plus_grand) et on appellera toujours en nommant les paramètres ma_fonction(plus_petit=.., plus_grand=...), c'est beaucoup plus sûr et surtout ça s'adresse au développeur, pas au compilateur. Le compilateur lui il se débrouille très bien tout seul, il n'y a qu'à voir les prouesses de pypy.

C'est important les humains qui changent les api justement...

L'upgrade est un problème quand le rapport difficulté/gain n'est pas bon. Hors il dépend intimement du langage. En python par exemple, faire évoluer un programme est à a fois facile et apporte beaucoup. Les problèmes de compatibilités sont donc largement amortis. En revanche avec un langage beaucoup plus difficile à faire évoluer effectivement le ratio n'est pas toujours bon on a beaucoup plus intérêt à ne pas casser la compatibilité ascendante.

Concrètement les programmes en C que j'ai écris il y a 20 ans ils seront sûrement compilable sans rien changer, mais de toutes façons de fait je ne les compile plus et je ne les réutilise pas non plus. En revanche les programmes en python que j'ai écris il y a 8 ans ils ont évolués tous les ans, malgré les pertes de compatibilité je les utilise toujours.

Bref, il ne faut pas prendre en compte que la compatibilité d'un code avec le langage mais aussi la compatibilité d'un code avec soit-même ;-)

On parle d'auto-hébergement quand la personne (physique ou morale) gère elle-même le fonctionnement au jour le jour d'une infrastructure qui est dans le même bâtiment qu'elle

On dit quoi quand la personne gère elle-même le fonctionnement mais pas forcément dans le même bâtiment ? Parce que c'est quand même le sujet... Sauf erreur, Denis parle d'exim vs gmail, pas tant d'exim sur adsl vs gmail.
On peut facilement passer d'un hébergement adsl vers un hébergement dédié si on a des soucis de disponibilité matériel, sans pour autant remettre en cause ce qui nous concerne avant tout, la partir logiciel. Comme la partie logicielle est facilement redondante et cryptable le soucis des données est bien moindre.

On a bien compris, pour toi les mails ne sont plus ton affaire, tu les sous-traite à un prestataire de service, comme tu prendrai un taxi au lieu de ta voiture que tu répare toi-même. Et donc tu te fout pas mal de savoir si la voiture du taxi est réparable ou pas ni si le chauffeur note dans son carnet où tu te rends et à quelle heure. Mais dans ce cas ce qu'on ne voit pas c'est qu'est-ce que ça peut bien faire dans un journal qui traite de la mécanique à faire soit-même ?

Si on trouve que gérer ses mails soit-même est une perte de temps, on ne va perdre son temps à lire des journaux comme linux mag non plus. Lorsqu'on fait le choix de gérer ses mails généralement c'est qu'on a une bonne raison. Le temps et la difficulté sont secondaires dans ce cas.

On n'est pas bloqué et il n'y a pas de surprise vu que la version 2 est encore maintenue et pour pas mal de temps encore...
Du reste, dans la plupart des cas la migration sera triviale, le seul problème c'est les librairies et ça c'est valable pour tous les langages même s'ils ne changent pas eux-même...

La pérennité du code c'est valable dans une bulle, et dans ce cas peu importe si le langage évolue ou pas...

Il faut plutôt se demander pourquoi un logiciel serait non libre. Quel est l'intérêt d'un logiciel non libre ? Le projet GNU a démarré parce que Richard a demandé un bout de code à un copain et que pour la première fois il le lui a refusé.

Aujourd'hui on peut changer la roue de son vélo tout seul et on peut s'échanger des recettes de cuisine, si demain on m'empêche de le faire, je vais râler, est-ce que j'ai besoin de me justifier ? de m'appuyer sur une philosophie ? de savoir peser le pour et le contre de telle variation ?

Donc le mois prochain tu nous fais un gros titre "Comment se débarrasser de gmail" et t'es pardonné. Sinon on appelle nos potes anonymous et on t'inonde de mails 8-D