Philippe F a écrit 2204 commentaires

Je suis sur que qq'un prenant la peine d'apprendre le langage de macro de OpenOffice peut reussir a faire la meme chose. Au final, a mon avis, il n'investirait pas moins de temps que toi tu en as mis pour apprendre Latex.

Perso, depuis que j'utilise OpenOffice, c'est le bonheur. Je ne fais que de la doc d'entreprise. Les template sont super facile a manipuler, en 3 secondes, je peux changer le style de tous mes titres, etc etc.

C'est quoi l'api crypto de linux ? Linux permet de generer des cles RSA ? De faire des verifications de signature RSA ? D'encrypters des donnes en triple DES et AES ?

==> NON !

Je ne sais pas de quelle api crypto tu parles, mais clarement, linux ne suffit pas pour coder une application avec de la crypto. Il faut utiliser utiliser une lib qui code tous les algos. En general, on utilise openssl (www.openssl.org) mais rien n'empeche de le re-ecrire.

> T'es gentil et tu me montres où j'ai écris ça ?

Je n'ai rien dit de tel. Je te fais remarquer que ton voeu pieu va avec une charge de travail telle que ca me parait peu probable qu'il soit realise. Mais j'aimerai qu'on me prouve que j'ai tort.

C'est justement ce genre d'interview ou la retranscription va prendre encore plus de temps que les 10 minutes par minutes, et que seul une minorite de gens pourront faire.

Il est clair que les editeurs chinois ont du aussi faire jouer leurs relations. Mais je doute que les editeurs associes arrivent au 10 000 e de la puissance de Microsoft, que celle-ci soit commerciale, financiere ou de lobbying.

Donc pour moi, c'est bien une victoire du petit contre le grand, et la seule raison qui puisse expliquer cette victoire c'est l'application d'une loi de preference nationale.

Moi ce que je cherche, c'est vraiment un bon debuggeur python portable. Pour l'instant, j'ai que dalle. J"arrive pas a me faire a pdb et je n'ai pas trouve de debugger potable. Je compte essayer eclipse prochainement, j'espere qu'il s'en sortira bien...

La Chine est en pleine mutation, et on y retrouve deux systemes qui s'affrontent, d'un cote l'ancien systeme gouvernemental, corrompu, qui marche a coup de relations, de reseaux et de pots de vins. De l'autre, les lois que la Chine fait passer pour se transformer en pays moderne (et ultraliberal).

Honnetement, je suis surpris que ce soit les petits editeurs Linux qui reussisent a l'emporter en invoquant une loi, face a la corruption + la machine Microsoft.

C'est une tres tres bonne nouvelle, d'une part pour le logiciel libre, d'autre part pour la Chine puisque ca montre son entree (certe, chaotique, difficile et imparfaite) dans un etat de droit.

Pour une fois, la technique du dealer de drogue de Microsoft n'a pas marche: tiens, prends mes premieres licences, elles coutent pas cher.

Esperons d'autre transitions vers le logiciel libre, et d'autres lois appliquees plus fidelement.

Ce qui me chagrine, c'est qu'il n'y a pas comme objectif d'avoir un driver/bootloader/machin truc pour le faire marcher sous windows. C'est vraiment impossible ou c'est juste trop complique a faire pour l'instant ?

Quand je vois des programmes qui sous windows, creent des lecteurs de DVD virtuels, je me dis que ca doit pas etre impossible au moins de rendre les partitions visibles, et au mieux d'y installer windows.

Certe, on est sur linuxfr mais l'interet d'avoir plusieurs partitions, c'est bien d'avoir plusieurs OS disponibles.

Chuis vert, j'ai passe 10 minutes a mettre ce post en forme et tout est nique parce que j'ai appuye sur le mauvais bouton au mauvais moment.

Ca sert aussi dans le cas de test unitaires pour faire des objets 
moqueurs (www.easymock.org).

Exemple:
def my_communication_protocol( my_interface, data ):
    # call many methods of my_interface
    # depending on the execution of each of them, handle
    # the communication protocol
    # return the result

Maintenant, comment on teste un bazar pareil ? J'ai justement eu le 
probleme recemment ou j'ai du ecrire exactement ce genre de code, 
une fois en C++ et une fois en python. 

En C++, j'ai du creer une interface generique, rajouter des 
methodes virtuelles, passer pas mal de temps a memoriser les 
echanges et pas mal de temps a tester mon objet de test. En 
python, c'est 10 fois plus simple. Tu passes un objet mock qui va 
enregistrer tous les appels qui seront faits sur ton interface et qui 
peut eventuellement retourner des donnees fictives. 

Exemple reel tire de mon code de test:
   # correct data, correct sw my_rd = Mock( 
   { "exchangeApdu": data + sw, 
      "powerOn": [0x3B, 0] } ) 
   sp = ScriptPlayerBase( my_rd ) 
   sp.setUnexpectedRaisesException( 0 ) 
   my_rd.clearCalls() 
   self.assertEquals( sp.send( cmd, sw=sw ), data + sw ) 
   allCalls = my_rd.getAllCalls() 
   self.assertEquals( len(allCalls), 1 ) 
   self.assertEquals( allCalls[0].params[0], cmd ) 


- my_rd est un objet fictif qui retournera data+sw a la methode 
exchangeApdu, et la liste [0x3B, 0x00] a la methode powerOn. 
- je le passe a ScriptPlayerBase en lieu et place d'un objet lecteur 
reel 
- j'appelle la methode send sur my_rd. Derriere mon dos, sp va 
appeler my_rd et recevoir les reponses qu'il attend 
- je verifie que la reponse est correct de send est correcte 
- ensuite, je liste tous les appels effectues sur my_rd et je verifie 
qu'ils sont bien ce qu'ils doivent etre. Les capacites dynamiques de 
python permettent de faire facilement ce genre de chose. Le code 
pour la classe Mock fait 80 lignes commentaires et documenation 
comprise. 

Pour faire le meme test en utilisant une methode a la 
EasyMock, on aurait: 
  # correct data, correct sw 
  my_rd = EasyMock() 
  my_rd.record() 
  my_rd.powerOn() 
  my_rd.setReturn( [0x3B, 0 ] ) 
  my_rd.exchangeApdu( cmd ) 
  my_rd.setReturn( data+sw ) 
  my_rd.replay() 
  sp = ScriptPlayerBase( my_rd ) 
  sp.setUnexpectedRaisesException( 0 ) 
  self.assertEquals( sp.send( cmd, sw=sw ), data + sw ) 
  # if something went wrong, an exception would have been raised 

Malheureusement, personne n'a encore ecrit d'easymock pour 
python. Mais ca doit bien demander une heure de travail a tout 
casser.

Ben voyons. Et ca va s'ecrire tout seul ?

Pour faire une retranscription d'une interview audio, il faut compter 10 minutes pour retranscrire une minute d'interview (experience vecue, http://dot.kde.org/1081772638/(...)). Pour de la video, c'est encore plus complique puisqu'il faut apres synchroniser les sous-titres.

La, il y avait une quinzaine de video de 45 minutes a l'akademy: 15 * 45 * 10 = 6750 minutes = 110 heures a quelques poils pres, uniquement sur la partie audio.

A mon avis, c'est plus rapide d'apprendre l'anglais.

Ca sert aussi dans le cas de test unitaires pour faire des objets 
moqueurs (www.easymock.org).

Exemple:
def my_communication_protocol( my_interface, data ):
    # call many methods of my_interface
    # depending on the execution of each of them, handle
    # the communication protocol
    # return the result

Maintenant, comment on teste un bazar pareil ? J'ai justement eu le probleme recemment ou j'ai du ecrire exactement ce genre de code, une fois en C++ et une fois en python. En C++, j'ai du creer une interface generique, rajouter des methodes virtuelles, passer pas mal de temps a memoriser les echanges et pas mal de temps a tester mon objet de test. En python, c'est 10 fois plus simple. Tu passes un objet mock qui va enregistrer tous les appels qui seront faits sur ton interface et qui peut eventuellement retourner des donnees fictives. Exemple reel tire de mon code de test: # correct data, correct sw my_rd = Mock( { "exchangeApdu": data + sw, "powerOn": [0x3B, 0] } ) sp = ScriptPlayerBase( my_rd ) sp.setUnexpectedRaisesException( 0 ) my_rd.clearCalls() self.assertEquals( sp.send( cmd, sw=sw ), data + sw ) allCalls = my_rd.getAllCalls() self.assertEquals( len(allCalls), 1 ) self.assertEquals( allCalls[0].params[0], cmd ) - my_rd est un objet fictif qui retournera data+sw a la methode exchangeApdu, et la liste [0x3B, 0x00] a la methode powerOn. - je le passe a ScriptPlayerBase en lieu et place d'un objet lecteur reel - j'appelle la methode send sur my_rd. Derriere mon dos, sp va appeler my_rd et recevoir les reponses qu'il attend - je verifie que la reponse est correct de send est correcte - ensuite, je liste tous les appels effectues sur my_rd et je verifie qu'ils sont bien ce qu'ils doivent etre. Les capacites dynamiques de python permettent de faire facilement ce genre de chose. Le code pour la classe Mock fait 80 lignes commentaires et documenation comprise. Pour faire le meme test en utilisant une methode a la EasyMock, on aurait: # correct data, correct sw my_rd = EasyMock() my_rd.record() my_rd.powerOn() my_rd.setReturn( [0x3B, 0 ] ) my_rd.exchangeApdu( cmd ) my_rd.setReturn( data+sw ) my_rd.replay() sp = ScriptPlayerBase( my_rd ) sp.setUnexpectedRaisesException( 0 ) self.assertEquals( sp.send( cmd, sw=sw ), data + sw ) # if something went wrong, an exception would have been raised Malheureusement, personne n'a encore ecrit d'easymock pour python. Mais ca doit bien demander une heure de travail a tout casser.

<< Le 'Explicit is better than implicit' est un argument creux: si c'était le cas, on programmerait toujours en assembleur: il n'y a pas plus explicite comme language. >>

Au contraire, l'assembleur est plutot obscur comme langage. Python est d'une clarte limpide a la lecture et ca, ca vaut cher.

J'avoue que ca me gonflait aussi un peu au debut, maintenant, je m'y suis fait meme si je l'oublie de temps en temps, ou si je le rajoute sur des fonctions qui n'en ont pas besoin.

Note que ce n'est pas le seul langage qui demande a declarer explicitement l'instance de l'objet. C'est le cas aussi pour lua, il me semble que c'est aussi le cas pour javascript et je suis sur qu'on peut en exhiber un certtain nombre comme ca.

C'est difficile de faire des tests unitaires qui couvrent tout. C'est tres tres facile de faire des tests unitaires en python mais sur mes programmes, malgre la palanquee de test, il y a toujours des cas non testes.

On peut eventuellement utiliser des outils de couverture de code (valider que les tests unitaires exercent tous les chemins) mais je ne suis pas sur ca suffise.

Typiquement, comme les type sont dynamiques, je me retrouve souvent a abuser un peu de ca, et ca peut faire mal:

def f( a ):
if not type(a) is type([]): a = [ a ]
# now, treat a as a list

def g( b ):
if type(b) is type([]):
for e in b:
g(b)

Dans ces deux cas, g et f acceptent deja deux types d'arguments (a noter pour les pythonistes que g peut s'ecrire plus simplement avec map).

En fait, je pense que ce n'est pas un bon style de programmation parce que c'est un peu dangereux. C'est avec ce genre de connerie qu'on se retrouve avec des chemins d'execution hyper complexes et qu'on peut lever une exception au mauvais moment.

Tu peux faire des trucs du type:

if KDE_SUPPORTED:
XMainWindow = KMainWindow
else:
XMainWidow = QMainWindow


class MyMainWindow( XMainWindow ):
....


En fait, ces possibilites tres dynamiques ne sont pas tant un besoin qu'une possibilite naturelle offerte par le langage.

Les methodes d'une classe sont stockees par exemple dans un dictionnaire attache a la classe, dictionnaire que tu peux manipuler a ta guise. Quel interet de les stocker dans un dictionnaire ? Il fallait bien les stocker quelque part. Quel interet de rendre le dictioninaire accessible ? Ben ca peut s'averer pratique dans certains cas mais Guido n'a pas vu de bonne raison de ne pas le faire.

Par exemple, tu peux faire beaucoup d'introspection en python en passant justement par ce dictionnaire. Alors que en C++, c'est particulierement lourd a faire. Meme en Java ou en .NET, l'api d'introspection est beaucoup plus limitee.

Les caracteristiques hautement dynamiques de python le rendent vraiment adapte pour faire des trucs un peu tordus ou des trucs complexes. Par exemple, la programmation oriente Aspect est hyper facile a mettre en place en python.

Mais faut pas croire que parce que il y a des super fonctionnalites, on doit les utiliser. Perso, je n'utilise que les fonctionnalites de base, je me sert de python comme d'un C++ leger et rapide, avec beaucoup de types de bases tres elabores et une large bibliotheque de fonctions.

Oui, Xemacs/emacs.

La version actuelle de gcc est issue d'un fork du gcc de la FSF, fork qui se nommait egcs. Dans ce cas, egcs a carrement remplace gcc, parce qu'il marchait beaucoup mieux. Cela dit, gcc n'est pas mort, les developpeurs se sont apercus de leur erreur et ont rejoint la nouvelle branche (au bout de deux ans si je me souviens bien).

Pour XEmacs, je ne suis pas un expert mais des gens informes m'ont dit que XEmacs etait beaucoup mieux que emacs. Ca n'empeche pas emacs de continuer sa belle vie.

Les forks sont lies soient a des problemes de personnes, soit a des visions differentes sur ce que doit etre le futur du logiciel (et en general un peu des deux). Les forks reussis sont tres tres rares. Le developpeur initial d'un projet a su amener le projet jusqu'a sa version actuelle garde beaucoup de pouvoir implicite et de respect de la part des autres developpeurs. Beaucoup de fork finissent dans l'oubli parce que le forkeur avait surtout une grande gueule et n'a pas reussi a amener l'ecosysteme minimal pour faire vivre un logiciel.

Inkscape est un fork qui reussit bien.

A mon avis, il ne faut pas avoir peur d'un fork parce que il a tres peu de chance de marcher. C'etait la peur no 1 de trolltech avant de mettre Qt en GPL et ils sont maintenant persuades que personne ne pourra developper Qt mieux qu'eux.

Bon, j'aime beaucoup ce langage. Simple, rapide a aprrendre, une lib de base tres tres complete permettant de faire a peu pres n'importe quoi.

Sa faiblesse vient a mon avis de son caractere hautement dynamique, qui l'autorise malheureusement a laisser des exceptions dans des coins tres sournois, qui ne seront peut-tres jamais mise en evidence durant les tests mais finiront par se lever en prod dans des condeitions bizarres.

Des outils comme pychecker ou peak aident a gerer ce genre de probleme mais je ne suis pas encore satisfait des limitations restantes.

Je reve d'un module qui aurait la force du compilateur de ocaml pour extraire l'ensemble des contraintes appliquees a chaque variable et qui en retirerait des erreurs, un peu comme ce qu'on a a la compile en C++.

Une incompatibilite qui me gonfle particulierement, c'est webdav.

Quand j'ai decouvert webdav, j'ai fait: ouai, super, un protocole qui permet de partager des fichiers de facon universelle (supporte par IE et Konqueror, j'ai pas trouve de plugin mozilla pour l'instant), en passant uniquement par http (donc pas de probleme de firewall) et relativement securisee (relatif au fait qu'il y a une authentification, je ne crois pas que ce soit crypte).

J'ai vite dechante. Le support webdav de IE n'est compatible qu'avec IIS. Ca marche pas avec apache.

C'est vraiment agacant ce genre d'attitude. Il va encore falloir attendre 10 ans pour que Microsoft daigne inclure la compabilite totale webdav dans la liste des fonctionnalites. D'ici la, webdav sera aux oubliettes et on aura un autre protocole standard mais que Microsoft aura encore une fois rendu incompatible.

Il ne faisait pas reference a Mozilla mais a certains browser qui utilisent le moteur html IE pour construire un browser. Par exemple, je sais que mon beau-frere chinois utilise un tel browser pour avoir une navigation avec onglet, un meilleur rendu des pages chinoises et autres ameliorations qu'on retrouve dans mozilla.

Il est tout a fait possible de faire des boucles, des branchements conditionnels et tout ce que tu veux en xml. En fait, tout est une question de mesure. Si tu dois vraiment ecrire un langage complet (assignation, boucles ...), autant le faire avec un vrai langage, qui a une syntaxe reconnue et familiere : javascript, lua sont par exemple tres tres facile a embarquer dans un executable et facile a programmer. C'est aussi le cas de lisp mais la syntaxe est plus difficile a maitriser.

Si tu dois juste faire un petit langage, le xml convient tres bien et a l'avantage d'etre facile a assimiler.

Le risque c'est evidemment de developper un langage qui prend plusieurs jours a apprendre, et donc de ne rendre les fichiers de config comprehensibles que pour ceux qui maitrisent ledit langage.

On peut noter aussi que Open Source est a ce point semblable au Free Software qu'il est victime du meme type de probleme semantique:

Pour les naifs:
- Open Source : logiciel dont on peut lire le code, conditions non precisees (NDA de preference, acces via le web a du code non compilable ...)
- Free Software : logiciel gratuit

Pour les geeks:
- Open Source : licence approuvee par l'OSI
- Free Software : licence approuvee par la FSF, et encore ...

Je veux pas etre mechant, mais utiliser le C comme langage de configuration et pretendre qu'on va simplifier la config me paraissent deux concepts qui n'ont rien a faire ensemble.

Pourquoi ne pas ecrire la configuration en assembleur ? Emacs a prouve aussi qu'avec sa config en lisp, c'est _difficile_ de modifier des options et de changer des trucs pour les debutants. Evidemment, c'est un regal pour les experts.

Je vois pas en quoi le C se prete bien a un langage de configuration. Ca veut dire qu'ils vont embarquer un mini-compilateur ?

A mon sens, il ne doit y avoir que deux types de langages de configuration:
- pas trop complexe : paires de cle / valeurs, eventuellement organisees en section (.ini sous windows, .desktop sous linux, fichiers de config sous KDE, lilo.conf, ....)
- complexe : xml

xml est assez lourd me se prete bien justement a des configurations complexes. Il est bien maitrise par tout le monde, c'est facile d'ecrire un frontend, de generer des config, de les verifier. Mais il ne faut l'utiliser que quand ca devient critique, avec plus de 100 cles et des hierarchies de config qui peuvent se customiser ou se surcharger.

La discussion a eu lieu recemment entre des developpeurs de KDE. Le consensus est que kdelibs + kdebase doit plutot fournir un seul logiciel par tache, dans la mesure du possible. KDE Extragear vient pour complementer.

Sinon, la multiplication des logiciels sous linux pour faire la meme chose est un probleme de longue date. Ce qui est particulierement penible, c'est quand tu as 5 logiciels differents pour faire la meme chose, dont aucun ne marche correctement. Ce n'est pas le cas de juk / amarok donc je me rejouis de cette multiplicite qui a marche.

Genial !

Enfin, tu es sur ? Tu appelles ca une fonctionnalite ? Donc il faut trois package (j'imagine que pgp/mime n'est pas fourni par defaut) pour installer kmail. C'est sur qu'avec ca, le linuxien debianiste se sent beaucoup plus intelligent:
<<
- t'as quoi comme distrib toi ? Moi j'ai une mandrake.
- t'as une mandrake: c'est nul! Regardes, si tu veux kmail, tu as kmail directement. Moi, sur ma debian, j'installe kmail mais je n'ai pas kmail ! Il faut aussi installer les fichiers de config, l'interface graphique, le pop3, le imap et pgp/mime. Pour konqueror, il me faut 24 package (avec tous les kpart, sachant que khtml n'est pas fourni par defaut) pour l'installer, c'est quand meme beaucoup mieux que d'installer un seul paquett.
- ben, je comprends pas ?
- tu vois pas l'interet ? C'est dingue. Ma distrib, elle est _optimisee_ . Tu vois, si je veux kmail mais sans le support de l'interface graphique, du pop3 et de l'imap, je peux. Alors que toi, tu gaches 0.005 euro d'espace sur ton disque dur [1] ! Les distribs comme mandrake, elles t'installent toujours n'importe quoi quand tu ne leurs demande rien. C'est quand meme incroyable qu'on puisse pas choisir entre kmail avec et sans pop3+imap.
- ah ouai, t'as raison. Je vais demander a Mandrake de splitter ses paquets comme debian. Mais si j'ai envie d'installer tout les logiciels de KDE, comment je fais ?
- pas de probleme. Tu connais la liste de 112 logiciels inclus dans KDE, et tu insalles a la main les 453 paquets qui servent a les faire tourner. Tu vois, linux ca assure !
- putain, c'est vraiment genial ce que tu me dis la. Quand je pense qu'avant, il me suffisait d'une dizaine de paquets pour obtenir pleins de logiciels. Comme j'etais naif.
- et attends, tu iras au devant de nouvelles decouvertes. Grace a apt-get (que RMS benisse ceux qui l'ont developpe), les 1237 paquets de dependances de tes 453 paquets sont installees automatiquement.
- putain, debian, ca assure vraiment un max !
>>



[1]: chiffre arbitraire en estimant que les options de kmail prennent 1 Mo et qu'un DD de 20 Go vaut environ 100 euro.

Je vois pas pourquoi il faudrait supprimer Juk ou Amarok. Ok, les deux applications font a peu pres la meme chose. Mais dans la mesure ou elle le font bien, sont maintenues et plaisent aux utilisateurs, pourquoi en supprimer une ?

Je suis un fervent partisan de la suppression des trucs qui marchent pas (noatun, arts, ...) mais juk et amarok, puisqu'ils plaisent, autant les garder.

Pour info, kdeextragear, c'est pas la cinquieme roue du carosse, c'est des paquets KDE officiellement maintenus qui peuvent faire des release independantes de KDE. Cet ensemble de paquetage prend de plus en plus d'importantce, tout simplement parce que le nombre d'application developpee avec KDE et le nombre de developpeurs augmentent.

Comme l'a fait remarque qq'un, les utilisateurs ne sont pas les memes. Pour mes parents, je mettrai plutot juk, car ca joue de la musique. Pour mon petit frere que ecoute de la musique 24/24, amarok convient mieux.

La legitimite de la plainte et l'importance qu'on y accorde viennent des membres de l'association. On ne s'improvise pas medef ou CCIA. Donc, c'est possible mais peu probable.

Je trouve le ton de ton message particulierement desagreable. Non pas que je defende les boites ou les personnes qui attaquent et defendent a coup de proces.

La survie d'une entreprise n'est pas une loi de la nature, pas plus que le commerce. Pourtant, on vie dans une societe ou on a besoin d'argent pour vivre, et une tres grosse part de cet argent est fourni par des entreprises, qui payent leurs employes.

<< si vous n'arrivez vraiment pas à faire de l'argent avec du libre, comme on dit, alors que d'autres y arrivent sans "tricher" >>

D'autres ? Le jour ou le nombre d'entreprise vivant du libre ne pourra plus se compter sur les doigts de mains, on pourra parler de modele economique rentable. Pour l'instant, on a des entreprises sur des micro-niches. Comment ca se fait avec le nombre de boites basees sur l'informatique qui se cree dans le monde qu'il y en aie si peu sur du logiciel libre ? Bah, tout simpelement le modele est tres difficilement rentable, donc il n'y a guere que les filous et quelques experts qui s'y risquent.

Ca me fait de la peine tout ca, je vais retourner a mon travail d'entreprise et baiser quelques concurrents avec des methodes mafieuses puisque je n'ai pas le choix.


ps: ne pas poster sur linuxfr quand on est deprime