wilk a écrit 1094 commentaires

Pour répondre brièvement, de la part de quelqu'un qui comme toi utilisais vi depuis une 15aine d'années et emacs pour tout ce que vi ne permettait pas, on peut dire que vim est un vi avec tout ce que peut faire emacs _si j'en ai besoin_... Depuis je n'utilise plus que vim, bien content de n'avoir qu'un seul éditeur à mémoriser depuis tant d'années...

Je comprend ton dégout, d'autant plus que tu as également du contribuer à tla et donc du subir d'autres déceptions, me trompe-je ?

Surtout que c'est ridicule d'avoir abandonné bazaar-1 et tout passé précipitement sur bazaar-ng alors qu'il n'est pas du tout prêt avec des changements de formats en cours ! Ca ne peut au contraire que le freiner, on le voit bien depuis quelques temps où le dev oscile entre quelques changements radicaux et des optimisations précipités...

Privilégier la politique c'est déjà ce que tu fais avec les logiciels libres. Ensuite, qu'ils soient ou non supportés par tel ou tel boite ou individu ça n'assurera hélas rien... Si la technique et l'équipe est la meilleure comme je le crois également, c'est la meilleure garantie pour cette fois-ci ça se passe bien et surtout que ce soit pérenne, c'est vraiment ce qu'on demande d'un gestionnaire de version...

En particulier, je ne cracherai pas sur un coup de main pour le support jabber qui est à l'heure actuelle plus que sommaire (mais ça marche...).

J'ajoute que le code est libre. S'il n'y a pas de lien download c'est uniquement parceque je n'ais jamais pris le temps de rendre le code présentable et encore moins de l'accompagner d'une doc... Si quelqu'un voulait y participer (c'est du python aussi) je partagerai tout ça avec grand plaisir.
La différence avec les autres projets c'est que toute l'interface est en html pour qu'il n'y ait rien à installer chez les joueurs.

Pour calculer le TOP, je me sert du programme eliot, qui est incroyablement rapide et n'a jamais été pris en défaut sur quelques dizaines de milliers de parties : http://www.nongnu.org/eliot/

La marque est déposée mais heureusement pas encore les règles du jeu. Du moins en France... (J'ai également reçu des couriers de menace mais il n'y a jamais eu de suite lorsque je leur ait demandé des informations légales en France).
La menace est évidement grande du côté des brevets, une règle du jeu, un algo...

Pour ma part ça m'a permis de sensibiliser les joueurs de scrabble lorsqu'il a fallu s'exprimer sur les brevets.

Du coup mon site s'apelle SEPS. Seps N'est Pas Scrabble ;-)

Si tu regardes bien, quand on programme on ne tapes pas beaucoup et on ne fixe pas non plus beaucoup l'écran. On tapes un peu, on lève la tête pour voir si la solution ne serait pas par hasard déjà écrite au plafond, si ça suffit pas on gratte la barbe dèsfois qu'elle se soit caché dedans etc. Tout ça mine de rien ça relache les tensions.
T'as pas remarqué à quel point il est beaucoup plus fatigant de taper une doc par ex ?

Donc, pour soigner vos douleurs : programmez ! Et si ça ne marche pas choisissez un programme plus compliqué !

J'ai eu la même chose suite à un suspend2disk... Très curieux effectivement...

Après avoir eu un crash avec reiserfs, j'ai eu la mauvaise surprise de voir que tout semblait correct (avec un fsck) alors que les fichiers ouverts lors du crash étaient corrompus ! Ca me semble doublement grave, perdre des données soit, on restore , mais si on ne sait pas lesquels...

Je suis alors tombé sur cet article : http://www.gentoo.org/doc/en/articles/afig-ct-ext3-intro.xml qui explique assez bien le problème et pourquoi ext3 n'a pas ce problème par rapport à reiserfs, xfs et jfs.

Si tu as très peu de tables, uniquement en lecture seule et que tu recherche la perf à tout prix ce qui est irréaliste c'est d'utiliser un sgbd, et encore moins des requêtes à base de like %... Pis j'ose espérer que les applis dont tu parles utilisent un système de cache sinon c'est pas sympa de maltraiter des sgbd comme ça qui n'ont fait de mal à personne.

Et dans ce cas postgresql n'a vraiment rien à foutre là, pourquoi pas comparer mysql avec fseek tant qu'on y est ;-)

Je brille bien là ou faut que je frotte encore ?

Pourquoi ne pas plutôt faire des benchs en prennant en compte des situations plus réalistes et qui tirent partie des atouts des sgbd ?

Par ex on prend un table entête reliée à une 50aine de tables, lorsqu'on supprime un enregistrement de l'entête il faut d'une part que tous les enregistrements liés soit supprimés, et d'autre part que soit tous soient supprimés soit aucun pour garantir l'intégrité des données.
Avec mysql il va falloir faire autant de requetes que de tables liés et faire toute une gymnastique pour faire l'équivalent d'une transaction. Alors qu'avec postgresql une seule requete suffira, toute la machinerie sera exécuté côté serveur sans pour autant bloquer d'autres utilisateurs (contrairement à sqlite) ni surcharger le réseau (la bdd étant bien entendu sur une autre machine)...

Je ne parle pas de couche métier dans la bdd, mais simplement du fait que quand on parle de perf sur une bdd ça vient rarement du langage lui-même mais plutôt de la structure des données, mauvaise requete, mauvais index etc, donc un problème d'analyse...

Oubien on parle simplement de quantité de données à traiter, mais alors ça n'a rien à voir avec une bdd, d'où l'ambiguité de la question.

Google utilise copieusement python par ex, mais ça ne nous apprend rien sur les perfs de python !

Si tu connais déjà bien les applis web, pourquoi ne souhaites tu pas continuer dans ce sens ?
Si c'est l'installation d'un serveur qui t'embête tu peux très bien créer un exécutable indépendant qui fasse serveur et bdd tout en utilisant le navigateur comme interface graphique.

Par exemple tu peux remplacer avantageusement apache+php+mysql par python+sqlite+py2exe.

Ta question à propos des "logiciels de gestions recevant de gros résultats de requete sql" n'est pas très compréhensible...

Si ça peut te rassurer je bosse régulièrement sur des grosses bases oracles et postgresql, python ne pose aucun problème particulier... Mais généralement quand on à un problème de perf à cause de "gros résultats sql" c'est que l'analyse n'est pas bonne et qu'il faut déléguer plus de taches au moteur de la bdd.

Le développeur lobotomisé effectivement il restera inféodé...
Après, a savoir s'il doit se former pendant ses 35 heures de travail ou pas, je te laisse choisir ;-)

Bon, allez, vitef : http://flibuste.net/libre/wilkdev

Comment-ça on ne dispose pas de liant ? Justement, on applique souvent le terme de "glue" aux langages du type python qui permettent de faire du développement rapide en s'appuyant sur n'importe quel éditeur, librairie graphique, outil de version, base de données etc... C'est un peu long de trouver tout ce que l'on veut coller ensemble mais une fois trouvé on devient beaucoup plus productif qu'avec des outils propriétaires du type windev où l'on est condamné à utiliser ce qui est pré-choisi, avec souvent un nivellement par le bas (il n'y a qu'à comparer chaque élement de windev avec les meilleurs équivalents libres).

Je ne sais pas ce qui te fais dire qu'il manque de développement professionnels sous Linux, mais il faut aussi tenir compte des développements qui tournent sous windows mais qui sont réalisés avec des briques libres. Peu importe le nombre, je peux te dire qu'en ayant transféré tous mes devs windev sur des briques libres j'y ai énormément gagné en productivité. Et attention, développer 10x plus vite qu'avec un outil qui permétait de développer déjà 10x plus vite, ça décoiffe ;-)

Ca fait qq temps que j'ai envie de faire une parodie de windev, wilkdev où je reprendrai les arguments de pcsoft en prenant des briques libres équivalents que j'utilise... ça m'éviterai de me répeter...

Pour ton commentaire, windev avait un intérêt il y a 10 ans où il était très difficile de trouver soit-même tous les outils qu'il regroupe (interface, états, versions, bdd, langage etc...)
Aujourd'hui grace aux logiciels libres on peu choisir soit même toutes les briques dont on a besoin, avec l'avantage de pouvoir changer une brique en cours de route sans trop de dégat.

On pourait publier pleins de combinaisons d'assemblages, mais quel intérêt ? Le choix des briques est un peu plus long, mais à l'arrivée l'efficacité est bien plus grande.

Pour quelles raisons les décentralisés ne sont pas abordables ? Il me semble au contraire, que de ne pas avoir à installer de serveur et gérer des droits d'accès rend les systèmes décentralisés beaucoup plus abordables. Plus besoin d'avoir un isp spécialisé : un simple site web http suffit, voir un compte mail...
Je me souviens que lorsque tuxfamily a connu des problèmes il y a eu un engouement énorme pour les décentralisés, les mailings-lists de ces gestionaires ont connu immédiatement un afflux francophone !

Souvent on trouve les systèmes décentralisés trop complexes parcequ'on regarde les fonctions avancées, mais il est tout à fait possible de se contenter des commandes de bases, et dans ce cas c'est bien plus simple que cvs ou svn.

Pour moi c'est bazaar-ng et roundup. L'avantage c'est que ce sont deux outils (non liés actuellement) très simples à mettre en place et à utiliser. Ecrits en python, ils sont prévus dès le départ pour être personalisables aux petits oignons.

C'est bien malheureux d'utiliser des benchs pour dire qu'un langage n'est pas lent...

Justement l'intérêt de python c'est que tu n'as pas besoin de te taper la doc pendant 5 ans pour en voir l'intérêt. Il n'y a rien de révolutionnaire là dedans, juste que de ne pas avoir à ce casser la tête pour comprendre le langage lui-même permet de se casser la tête pour autre chose, les specs par ex dont on a vu qu'elles étaient bien plus importantes.

Pour ce qui est des millions de lignes de code, on a vu aussi que c'était une abération de conception et qu'il faut impérativement découper tout ça en de plus petits projets. Donc chercher des exemples de mauvaise conception pour voir comment on s'en est sortie quand même n'as aucun intérêt.

Une ligne de python révolutionnaire ? c'est simple : print "hello world"

Pourquoi c'est révolutionnaire ? parcequ'on peut rester simple pour ce qui est simple.

L'exemple le plus connu est la comparaison entre la lecture d'un fichier en java et en python...

Ha bon ? demande à google pour voir ;-)

Si les langages de la nature de python aident à réduire le nombre de bugs c'est tout simplement parcequ'ils sont agréable à utiliser. Se faire plaisir en programmant est sûrement la meilleure garantie contre les bugs. L'esprit humain est ainsi fait, et non seulement de logique. Il n'y a qu'à regarder un enfant à l'oeuvre, s'il s'amuse ça marche, s'il se fait chier il n'avance pas. Les statistiques montrent par exemple que les personnes qui font de l'informatique à la maison (pour le plaisir) n'ont pas du tout les même problèmes (douleur au dos, maux de tête etc.) que ceux qui travaillent.

Je vous trouve bien naïfs à toujours prendre l'exemple de l'industrie, des centrales nucléaires ou des télécoms comme domaines où la programmation serait exemplaire. Ouvrez un peu les yeux, c'est vraiment très loin d'être le cas.

Et le danger est justement de croire naïvement que tout va fonctionner comme prévu, qu'il y a des outils, des langages et des personnes parfaites. Justement, s'il y a peut-être une différence dans l'industrie par rapport à d'autres domaines c'est qu'on sait dés le départ que ça ne marchera probablement pas et on prend les devants.

ps: je ne parle pas de l'article mais des nombreux commentaires

Ca n'empêche pas qu'on peut faire du suspend-to-disque sans acpi ni même apm, juste en soft. C'est pour ça qu'on dit software suspend d'ailleur... Après je suis d'accord que si ça pouvait être géré avec l'acpi ce serait encore mieux.

Sauf erreur de ma part, le suspend-to-disque est complètement indépendant de la config matérielle, c'est une option entièrement gérée par le kernel. Il stocke la ram dans la partition swap et éteind l'ordinateur. Lorsque l'on rallume l'ordinateur il recharge la ram, c'est tout, le bios, l'acpi etc n'intervient pas dans le processus.

Plus maintenant, sûrement à cause de lenevo. Par contre on ne sait pas ce que ça va devenir...