brunoc a écrit 15 commentaires

> Pour un industriel, l'objectif est de faire des bénéfices

Avant de faire des bénéfices, ne faut-il pas :
* fournir un service
* transformer de la matière
* produire de la matière
?

Il ne faut pas mettre la charue avant les boeufs... Le client d'un industriel achète ce que produit cet industriel, avec une considération secondaire pour sa "valeur économique" (modulo l'éventuel côté rassurant). Mandriva prend exactement le contre-pied de mon propos, et je suis certain que celà sonne son glas. Les clients se tourneront naturellement vers de meilleurs produits. Pour moi, l'objectif d'un industriel est d'avoir une activité (de service, de production) UTILE à la communauté de ses potentiels clients. Les bénéfices/déficit sont une conséquence :
* de l'intérêt de la communauté pour cette activité
* de la bonne gestion interne de l'entreprise

Malheureusement, ce n'est pas la tendance de notre époque, et celà contribuera certainement à notre déclin culturel, politique, social et à terme économique...

http://www.openbsd.org/faq/fr/faq1.html#HowAbout
http://www.apache.org/licenses/

Chez OpenBSD, ils sont TRES à cheval sur les licenses, et ça contribue à la personnalité du projet ! Et à leurs sens, la license d'Apache 2 n'est pas acceptable. D'où leur choix de se resteindre à Apache 1.3 dont ils maintiennent un fork dans leur distrib. Mais j'admet que j'ai du mal à comprendre, la license Apache 2 est compatible GPL et le projet BSD contient des briques GPL... En quoi la license d'Apache 1 est-elle plus approriée que la license d'Apache 2 dans le cadre du projet OpenBSD ?

Vite, postons chez eux...

C'est vrai qu'on serait vachement plus heureux en parlant tous la même langue, en bouffant tous la même bouffe et en ayant tous la même gueule. Ce que j'ai du mal à comprendre avec ce type de réflexion, c'est que la réponse semble venir d'en haut : le langage fait tout. Je trouve ça naze car à mon avis, même le langage le plus théoriquement parfait ne t'empêchera jamais de faire un gros tas de *erd*. Si tu dois bosser avec un nombre important de programmeurs et bah tu te mets d'accord sur un style commun, et le mec qui n'est pas d'accord -->[]. A mon avis, des contraintes stylistiques (car finalement, c'est à peu près la seule chose qui différencie les languages tip-top-dans-le-move du moment) trop fortes, ça bride l'initiative personnel et tu te retrouves à essayer de contourner ce que tu considèrera comme les limites du langage. Et un autre percevra d'autres limites. Et la question de la maintenabilité se repose alors encore. De plus, je ne pense pas q'un script perl soit fait pour être repris : the job is just done, même si c'est "crade". S'il ne fait pas exactement ce que tu veux, il n'est pas pour toi. Et de plus, je dirai que Perl répond facilement à des problèmes simples, donc si un script résoud un problème simple mais ne fait pas exactement ce que tu veux, une réécriture perl from scratch de la variante de ton problème sera simple.

Je suis contre l'appauvrissement des concepts à travers l'homogénéisation.
C'est aux gens de prendre les initiatives de ce qu'ils veulent dans la vie, en politique, en technique, en amour. Ca doit venir des boyaux. Pas du ciel.

Tchuss.

Une autre question que je me pose : perl a pour vocation d'être capable de tout (langage "glue"). Egalement, un autre aspect qui sous-tend le language est de pouvoir faire facilement des choses faciles et rendre possible des choses difficiles. Comme la plupart du temps, notre superbe esprit d'analyse et de décomposition des problèmes nous ramène nécessairement à des problèmes simples, perl serait donc un langage acceptable, voire recommandable, y compris pour des tâches complexes. De même, si notre suprême intellect échoue dans l'analyse d'un problème et abouti sur une solution complexe, le temps que je pourrai perdre à réaliser cette complexité en perl, de temps en temps, ce temps est largement compensé par le temps que j'ai de nombreuse fois gagné dans des réalisations "simple". Sans compter la valeur pédagogique (j'ai l'impression que perl est infini) et le facteur fun :)

Ca tient la route, non ?

Merci pour ta réponse.

Pour la partie multi-thread, le module Net::Server n'est-il pas censé encapsuler toute cette complexité ? De plus, je ne crois pas vraiment en la pertinance des threads en dehors des io dans ce type de projet (dans le TAOUP, les threads ne sont pas considérés comme une bonne pratique. Bon, ça vaut ce que ça vaut). J'ai assez peu d'info sur le deuxième point que tu abordes : peux-tu préciser ou comparer avec d'autres langages ? Pour ce qui est de la programmation objet, je ne suis pas un afficionado et je ne comptai pas trop verser dans ce style. Pour ce qui est de la VM sous Windows, c'est pas grave :)

Bon, celà dit, je crois que j'ai posté un peu vite... Pour la partie serveur, il y a jabberd ( http://jabberd.jabberstudio.org/(...) ) qui semble déjà faire ce que voudrai. Et je crois que tu as raison : c'est très ambitieux. Peut-être juste se limiter à un client au début.

Peux-tu me faire rapidement part de ton expérience dans la programmation Perl : ce qui t'as (dé)?plu ? Ne crois-tu pas que Perl soit aussi adapté pour le développement d'un serveur Jabber que OCaml pour un démon de p2p ? :) L'inesthétisme de Perl est-il inéluctable ? Pour ma part, je dirai qu'on peut parler un français littéraire, moderne, moyen-ageux, argotique, etc. N'en est-il pas de même pour Perl ?

J'ai aussi eu ce type de problème sur mes serveurs, j'avais appliqué les mêmes conseils que tu proposes et ça fait fuir beaucoup de gens :)

Par ordre d'efficacité décroissante :
1) authentification uniquement par certificat (empêche direct les brute forcer et les connexions non authorisées)
2) désactivation des connexions root (t'empêche de faire des conneries sur tes serveurs, use sudo, luke)
3) utilisation stricte du protocole v2 (empêchera un thésard en cryptologie de casser ton DSA ou je sais pas quoi :)
4) changer le port d'écoute (sers à rien mais c'est marrant)

Je crois que déjà là c'est pas mal.
Eventuellement, je pense qu'on doit pouvoir pousser le vice avec PAM et une authentification à base de token physique ou ce que tu veux, mais ça n'est peut-être pas nécessaire...

Ce qui semble vraiment fabuleux dans la dernière version d'iChat, c'est le support audio/video qui semble vraiment tip-top. Comme dans Tiger, iChat supporte maintenant Jabber, et que ce dernier est un protocole extensible, on pourrait espérer qu'Apple utilise ce dernier pour le transport des flux im et porte ses fonctionnalités multimédia sous forme d'extension standard au protocole Jabber. Ce serait vraiment une belle contribution pour le libre, et je pense que l'image d'Apple n'en serait qu'améliorée... J'aime bien leur politique de "on utilise des produits libres, on le cache pas, on en est fier et en plus on contribue (launchd)". A quand des acteurs du monde propriétaire comme moteurs de projets libres ?

Entièrement d'accord ! Le BIOS est un archaisme qui remonte quasiment à l'époque des 8086 à 4MHz qui n'a plus lieu d'être !!!

L'Openfirmware est une spécification assez ancienne mais énormément déployé dans le monde "non-pc" : apple, as/400, mainframe... Il fournit un cadre beaucoup plus puissant pour le boot d'une machine, car programmable (en forth : il y a même un mec qui a développé un Pong pour l'openfirmware ! cf http://seriot.ch/Pong(...) ).

Je trouve dommage que trop souvent les PC restent embourbés dans des normes antédiluviennes sous prétexte de compatibilité ascendante au niveau hardware alors qu'à 95%, au dessus il y a un Windows avec des produits avec une durée de vie ridiculement faible... N'est-ce pas un parfait non sens ?

De plus, les specs de l'openfirmware sont complétement publiques : pourquoi insister à vouloir rester dans un carcan et à vouloir réinventer la roue ?

Bon... Moi, j'ai pas de PC (PowerBook dual Boot Linux/MacOS X). Serein sur la sécu (firewall + minimum de services)...

Ca se tient... Vendu !

> Le fait est que ce n'est pas la machine qui exécute directement le code pyc/pyo mais une pseudo machine, une machine virtuelle.

Muh ? Donc tout langage interprété est un langage à machine virtuelle, car introduisant un niveau de "virtualisation" ? Ca me parait un peu fort... J'avais plutôt l'idée d'une machine virtuelle qui encapsule totalement les supports matériels sur lesquels elle est lancée, fournissant ainsi une interface et un comportement identique pour toute implémentation, genre Java. Mais Java n'interprète-t-il pas un bytecode compilé pour sa VM ?
Bon, c'est vrai qu'au final, c'est un peu flou... Quelqu'un connait précisément les différences entre un langage interprété et un langage à VM (s'il y en a).

Voici ce que j'ai compris du fonctionnement de Python : Python est naturellement un langage interprété. Les fichiers .pyc (ou .pyo) sont une forme optimisée du résultat de l'interprétation par Python. Sous cette forme, Python n'a pas à se re-goinfrer toute son analyse syntaxique et sémantique (faible d'ailleur, puisque typage dynamique). Une des différence entre un .pyc et un .pyo, c'est que le dernier ne contient plus les docstring (quelqu'un connait-il d'autres différences ?)

Mais c'est bel et bien une interprétation de cette forme optimisée qui est mise en oeuvre. Dans tous les cas, je ne pense pas que l'on ait à faire à une machine virtuelle : de nombreux modules de base (syslog, win32, fcntl, etc...) dépendent de l'OS sous-jacent. Ce principe est contraire au fonctionnement d'une VM. Tu me diras, Java utilise une VM et avec JNI, tu peux forker et autres unixeries. Oui.

Je trouve que Thunderbird est un excellent client de messagerie. Mais ce qui lui manque à mon goût se sont des fonctions orientées groupware (gestion de calendrier collaboratif, par exemple). Il y a bien l'extension 'Calendar' mais il n'y a pas encore de version compatible avec la version 1.0 de Thunderbird. De plus, l'ergonomie & l'esthétique de cette extension, font vraiment old-school.

Ok. Et quand utilise des packages en testing tu as généralement quel niveau de "nouveauté" (ou d'ancienneté, selon le point de vue) ?

Merci pour tes précisions. Mais quelle est la façon la plus simple pour mettre à jour mon install stable (& deprecated) : refaire une install à partir de CD "testing" ou mettre à jour les packages installé en version "testing" avec apt. Est-il possible d'avoir simultanément plusieurs versions d'un même package (genre pour faire marche arrière en cas de vrille complète d'une version testing) ? La prochaine version, Sarge, sera-t-elle la version "testing" du moment (Woody) passé en "stable" ? Quand est-ce que ça sors ? Que de questions assaillent mon esprit :)