Tout a fait. J'utilise py2exe. Cela dit, la seule raison pour laquelle ca a l'air close source, c'est que personne s'est trop penche sur le sujet. A ma connaissance, il n'y a pas de desassembleur python comme on trouve des desassembleur java ou C#, ce qui fait qu'une application python packagee reste "raisonnablement" close source.
Le produit s'addresse de toute facon a un marche non specialiste de l'informatique, donc je doute qu'ils me de-exe-ifie mon python. Et si ca arrive, il n'y a pas de secret dans les sources, c'est juste que les gens n'ont a priori pas besoin d'aller lire notre code. Donc je vivrai avec.
J'ai pas dit que j'aimais pas C# ou .NET. Mais si tu utilises toute la plateforme .NET, tu perds la portabilite car Mono ne couvre qu'une partie des lib .NET . Ca fait une grosse difference par rapport a PyQt, ou tout ce que tu fais et que tu apprends en PyQt sera toujours disponible sous Linux comme sous Windows.
Et j'aime beaucoup python, malgre ses nombreux inconvenients, donc pour moi faire du python + Qt est mieux que de faire du C# .NET
Ah au fait, c'est super les projets en Mono mais c'est con, Redhat ne peut pas distribuer Mono. Ca grille quand meme pas mal les utilisateurs americains.
<< Si tu est vraiment alergique a microsoft >>
Je ne suis pas allergique a Microsoft, il fait partie de la realite du monde du travail et Windows a l'avantage du proposer une API stable depuis 20 ans. Le kernel et la plupart des projets logiciels libres (pour lesquels j'ai le plus grand respect) ne peuvent pas en dire autant, ce qui fait que travailler sous windows a quand meme ses avantages.
<< Dis moi, tu n'a pas l'impression que venir dire ça sur DLFP, c'est comme se pointer sur un forum officiel Micro$oft et recruter des développeurs pour développer des progs open-source sous Linux ? >>
Non, je pense qu'un certaine proportion de linuxien sont largement plus ouverts que le developpeur moyen lobotomise par Microsoft. Donc la comparaison ne tient pas pour moi (attention, certains linuxiens sont bien plus lobotomises par le logiciel libre que Microsoft n'arrive a le faire avec ses developpeurs).
J'ai hesite avant de poster cet article.
Il se trouve que visiblement, il y a des gens qui malgre cet inconvenient de taille, sont interesses par la proposition.
Alors, voici mon raisonnement:
1. d'un cote un mec qui cherche des stagiaires competents et qui est passionne par le logiciel libre.
2. des stagaires competents qui cherchent un stage dans le logiciel libre ou a defaut un stage dans une ambiance de travail raisonnablement sympa.
Ce serait dommage de se rater, que je trouve un stagiaire qui n'aime ni python, ni Qt et que les passionnes de logiciels libres trouvent uniquement un stage ou il faut developper en asp.NET . Donc j'ai prefere poste ce journal au cas ou.
T'en connais beaucoup des stages ou tu fais du logiciel libre ? T'en connais beaucoup des stages ou tu peux faire du python ? du Qt ?
Un autre facon de voir la chose, c'est est-ce que t'as deja travaille dans une boite normale, avec des lobotomises de chez Microsoft ? J e peux te dire pour l'avoir fait que ce n'est pas la joie. Au moins chez nous, on peut discuter tranquillement des trolls du moment (novellcapueyapukde) dans une ambiance detendue.
A noter aussi que le savoir-faire que tu peux accumuler durant ce stage est utilisable directement dans des projets logiciels libres populaires : python, Qt.
Rien a voir mais qq'un pourrait m'expliquer la difference entre le style "corps de texte" et le style "standard" ? En "corps de texte", les liste sont tres espacees, ce qui ne fait pas tres joli. Mais ca a l'air d'etre pourtant le style recommande pour un paragraphe.
Je trouve ca inquietant quand meme que ca ne soit que maintenant que Gnome se soucie d'optimisation. Si on peut gagner 24% en deux jours, c'est vraiment qu'il y avait des problemes faciles a resoudre qui n'ont jamais ete regarde.
Cette histoire de glist en O(n2) est quand meme pathetique. C'est pas comme si on decouvrait un nouveau truc. On est en 2005, ca fait des annees qu'on connait des algorithmes et des heuristiques d'optimisations de liste. Optimiser une gestion de liste, c'est un exercice d'etudiant de 1e annee d'informatique. Se dire que l'un des meilleurs bureaux graphique de la planete en est encore la, ca fait peur.
Si tu regardes l'historique de glist, tu vois que ca n'a jamais pratiquement bouge. D'un cote, c'est bon signe, ca veut dire qu'elle a satsifait tous les besoins depuis des annees sans modification. Mais si tu regardes du cote de Qt, tu vois que au fil des ans, il y a eu pas mal de reflexion autour de la bonne facon d'optimiser une qlist.
Ca fait des annees que KDE se soucie de l'optimisation (la liste kde-optimize etant un symptome, creee en 2002), a cause de son image de bloatware. Quand je vois le niveau des mecs qui y poste d'ailleurs, je me sens tres tres humble.
Pour rappel, des trucs comme le prelinking ont ete inventes par des mecs de KDE, pour resoudre des problemes de performance du chargeur de lib de linux.
> Par contre, des qu'il s'agit de se vendre, la il n'y a plus personne.
C'est marrant, je connais des gens qui y passent beaucoup de temps et d'energie. Une annonce dans le new york times, j'ai du rever. Ou spreadfirefox, ca n'existe pas.
> Le libre qui aurait pu (qui pourrait encore) concretiser une belle utopie
Qu'est ce que je me marre. KDE a pris la decision de virer Corba en octobre 99. Il aura fallu plus de 5 ans a Gnome pour realiser que c'etait une bonne decision.
Ce qui est dommage, c'est que des mecs super comme Mickael Meeks aie passe autant de temps sur une techno qui sera jetee a la poubelle.
T'as rien compris au fonctionnement de freedesktop (qui soit dit en passant, est modele social des logiciels libres. De la a dire que tu n'as rien compris au modele social des logiciels libres, il n'y a qu'un pas que je ne franchierai pas).
freedesktop rassemble des hackers des differents desktop pour en faciliter l'interoperabilite. Freedesktop fait avant tout des standards, et propose en general une implementation de reference (DBUS).
Freedesktop emerge d'une necessite, celle de discuter interoperabilite en terrain neutre. Freedekstop n'a aucun pouvoir en dehors de celui des hackers individuels qui sont d'accord avec une proposition de freedesktop.
Pour DBUS dans KDE, l'idee semble faire son chemin mais c'est pas encore gagne. Ce qui est sur, c'est qu'il y aura un pont DBUS - DCOP de facon a conserver la compabilite.
Quand je vois la liste des modifications, je ne vois rien qui justifie de faire un saut aussi grand. Une 1.1 aurait parfaitement suffi a mon (pas si humble) avis.
Clairement, google, yahoo et consorts en s'installant en Chine, obeissent a une necessite commerciale (grossir) qui est amorale.
Une fois que ces boites s'installent sur place, elles ont deux choix :
1. lutter de toute leur force pour le respect des droits de l'homme et s'opposer a l'autorite chinoise
=> elles vont se faire tout simplement interdire et donc echoueront a leur objectif commercial.
2. accepter les regles antidemocratiques locales en fournissant leur service.
A noter que 2. est peut-etre plus utile que 1. Que vaut-il mieux un moteur de recherche censure, mais puissant et capable de trouver des pages peut-etre difficiles a trouver ou pas de moteur de recherche du tout ?
Meme si les boites dont on parle respectent le non-respect des droits de l'homme et censurent leurs resultats, il peut y avoir d'autres moyens plus discrets de lutter. Etre un excellent moteur de recherche permettant de trouver facilement des proxy caches ou des pages de protestation sur la Chine en est un.
Bon, je constate que git a evolue depuis que j'ai regarde de pres. Ca ne change rien au fond de mon argumentation, a savoir qu'il a ete developpe pour des besoins tres tres specifiques et qu'il ne peut ne pas convenir pour d'autres besoins specifiques aussi.
Il y a des gens qui se disent que si le kernel utilise un truc, c'est forcement le meilleur truc au monde. C'est a moderer fortement, les hackers du kernel n'etant pas des etres humains normaux, mais des hackers du kernel.
> Aucun des programmes que tu cites ne répondent à tous tes critères.
Ce sont des criteres en vrac. De fait, mon argumentation est justement qu'il n 'y a pas de SCM universel pour l'instant.
Dans ma boite mes deux commerciaux utilisent CVS quotidiennement sous windows grace a tortoise CVS. Ca ne serait possible ni avec arch, ni avec git, ni avec tla. Subversion serait envisageable. Malgre tous les inconvenients de CVS, c'est de loin une des meilleurs solutions par rapport a mon besoin.
J'ai oublie d'ailleurs dans mes criteres la facilite d'utilisation. CVS, un utilisateur utilise quotidiennement deux commandes : commit update. Rien qu'en voyant la page de man de git, je laisse tomber. Il va me falloir deux heures pour comprendre de quelles commandes j'ai besoin et lesquelles ne me servent a rien.
Et puis niveau stabilite, si la porcelaine evolue, ca ne convient peut-etre pas a tout le monde.
J'ai regarde le mode pack mais j'ai pas trouve de description de l'operation de packing qui est faite derriere. Je ne peux donc pas dire si c'est efficace ou pas comme methode de stockage.
Surtout, git est optimise pour les besoins de Linus. Le fait que CVS et subversions ne conviennent pas a Linus mais conviennent a des milliers de projets Open Source devraient deja donner un indice que git n'est pas pour tout le monde.
Quelques points notables:
- git stocke les fichiers integralement. Si tu changes une ligne a fichier texte de 50000 lignes, git restocke le fichier texte. CVS et consorts stockent un diff. Donc en terme de stockage, git n'est pas efficace et ce n'est pas son but.
- git est concu pour avoir une notion de tracabilite tres profonde, sur l'integralite des sources et des changements d'un projet, le tout valide par une signature cryptographique (SHA). Il est possible en une seule operation de savoir si deux jeux de source git sont identiques ou differents.
- git est optimise pour la notion de partage et de melange d'arbres differents, qui correspondent au modele de developpement du noyau : beaucoup de developpeurs avec des branches partielles (sous-systemes, experimentales) font d'abord des modifs dans leur branche avant de faire remonter la modif vers le repository de Linus.
Bref, pas grand chose a voir avec les besoins classiques d'un SCM :
- versionnement des fichiers
- remonter dans le temps sur les versions passees
- notion de branche
- notion de marquage (tag)
Apres, on peut rajouter d'autres fonctionnalites :
- commit atomiques
- renommage
- utilisation en mode completement decentralise facon arch
- interface conviviale
- compacite du stockage
- facilite de deploiement
- portabilite
- nombre d'outils et frontend associes
- stabilite
- dispoinbilite d'un frontend sous windows
qui font qu'on aboutit a CVS, Monotone, subversion, arch, tla, bazaar, bazaar-ng, Super CVS et autres.
Je sais que dans ma boite precendent, la convivialite etait un element fondamental. Si l'outil n'etait pas convivial, les developpeurs ne l'utilisaient pas et continuaient avec leurs zip sur un serveur partage. Chaque usage a ses criteres particuliers.
Tu te trompes en affirmant que ruby passera au premier plan, sous-entendu avant les autres langages que j'ai evoque.
Les avantages que tu cites d'ailleurs ne sont pas la pour offrir une bonne "scriptabilite" ( = capacite d'etendre et de controler une application par script ) mais un bon environnement de developpement.
KDevelop supporte deja d'autres langages que Ruby, et ruby est loin d'etre le seul langage a faire du dcop ou du soap.
Ruby va avoir une place confortable en terme d'IDE en effet, car Richard Dale, le M. Binding de KDE aime beaucoup ruby. Mais l'approche utilisee pour integrer les langages de scripts dans KDE est generique, et il y a des supporters d'autres langages dans KDE.
KDE 4 va etre quand meme avant tout la continuite des principes qui ont fait le succes de KDE depuis KDE 2. Tout ca pour dire qu'il y aura certainement des technos bien sympatiques, mais que ca ne va pas etre une revolution en interne. Qt4 offre de nouvelles possibilites qui seront exploites. Le fait de pouvoir casser la compabilite binaire va conduire a un nettoyage des libs internes. Mais globalement, on reste dans le meme principe.
Pour repondre a tes questions :
- du multithreading : il y a deux presentations sur les possibilites de faire des applications asynchrones et/ou multithreadees et toutes les deux ont semble-t-il bien marche. Donc il va y avoir une meilleure comprehension de ce qu'on peut faire en asynchrone. C'est pas pour ca qu'on va re-ecrire kdelib en multithreads.
- c'est quoi les _nouveaux_ standards de freedesktop ? KDE utilise deja la plupart des standards definis dans le cadre de freedesktop. Et participe a l'elaboration des futurs standards. Pas de revolution de ce cote-la, mais le travail de KDE s'inscrit dans la continuite.
- nouvelles applications : j'ai pas entendu parle de killer app. Cependant, ca fait plusieurs annees que Krita est developpe et il semble arriver a maturite. Il semble aussi qu'on se dirige vers un multi-viewer a base de KPdf. Il y a aussi la convergence de developpeurs, d'artistes et d'ergonomes dans le cadre du projet Appeal, avec notamment un nouveau bureau plus interactif.
Il semble aussi que la scriptabilite passe au premier plan dans KDE 4. Je n'y suis pas mais j'ai lu pas mal de gens discuter de facon d'introduire une interface de script generique au coeur des libs KDE, accessibles a divers langages de scripts : ruby, python et javascript au moins.
Globalement, il faudra attendre quelques mois pour comprendre tout l'impact de l'akademy 2005 mais il semble que ca soit bien parti.
Bon, on en revient a ma conviction premiere, a savoir que Linus, malgre toutes ses qualites, ne sait pas gerer un systeme de versionnage lisible et propre.
Pour comprendre ce que j'appelle lisible et propre, il suffit de regarder la facon dont fonctionne KDE ou Mozilla. Il n'y a pas 24 numero de versions, et les versions en dev s'appellent beta, alpha ou autre, les versions super stables ont un no de release unique, et les versions presque stables avant la release sont notes RC.
On peut suggerer a Linus que les versions dont les 4 chiffres sont multiples d'un meme nombre premier sont stables, celles ou la sommes des 4 chiffres est divisible par 7 sont des release candidate, et les autres sont instables. Ca me paraitrait a peu pres aussi lisible que le systeme actuel.
Je me demande si l'appellation bug n'est pas plus ancienne encore. Je me souviens d'un bugs bunny ou on voit un vilant "bug" essayer de faire exploser des bombes d'avions militaires. Il me semble du coup que c'est lie a une legende, de petits etres qui viendraient foutre la merde dans un truc cense marcher parfaitement.
Je suis surpris de voir les versions RC (candidats de sortie) associes dans la nouvelle avec la notion de deverminage.
Les RC, etant des candidats finaux, ne servent pas a deboguer mais a tester que tout marche, ce qui n'est pas du dout a mon sens la meme demarche. Apres, il peut y avoir des vermines [1] dans une version, qui doivent evidemment etre corrigees mais ce sont en theorie de vermines mineures.
La phase de deverminage a lieu normalement pendant le developpement de nouvelles fonctionnalites, c'est a dire bien en amont de la phase des RC.
[1] : j'avoue que j'ai quand meme du mal a ne pas appeler ca un "bug".
[^] # Re: Python en close-sources ?
Posté par Philippe F (site web personnel) . En réponse au journal Stage en python / Qt. Évalué à 2.
Le produit s'addresse de toute facon a un marche non specialiste de l'informatique, donc je doute qu'ils me de-exe-ifie mon python. Et si ca arrive, il n'y a pas de secret dans les sources, c'est juste que les gens n'ont a priori pas besoin d'aller lire notre code. Donc je vivrai avec.
[^] # Re: bof
Posté par Philippe F (site web personnel) . En réponse au journal Stage en python / Qt. Évalué à 4.
Et j'aime beaucoup python, malgre ses nombreux inconvenients, donc pour moi faire du python + Qt est mieux que de faire du C# .NET
Ah au fait, c'est super les projets en Mono mais c'est con, Redhat ne peut pas distribuer Mono. Ca grille quand meme pas mal les utilisateurs americains.
<< Si tu est vraiment alergique a microsoft >>
Je ne suis pas allergique a Microsoft, il fait partie de la realite du monde du travail et Windows a l'avantage du proposer une API stable depuis 20 ans. Le kernel et la plupart des projets logiciels libres (pour lesquels j'ai le plus grand respect) ne peuvent pas en dire autant, ce qui fait que travailler sous windows a quand meme ses avantages.
[^] # Re: Super !
Posté par Philippe F (site web personnel) . En réponse au journal Stage en python / Qt. Évalué à 7.
Non, je pense qu'un certaine proportion de linuxien sont largement plus ouverts que le developpeur moyen lobotomise par Microsoft. Donc la comparaison ne tient pas pour moi (attention, certains linuxiens sont bien plus lobotomises par le logiciel libre que Microsoft n'arrive a le faire avec ses developpeurs).
J'ai hesite avant de poster cet article.
Il se trouve que visiblement, il y a des gens qui malgre cet inconvenient de taille, sont interesses par la proposition.
Alors, voici mon raisonnement:
1. d'un cote un mec qui cherche des stagiaires competents et qui est passionne par le logiciel libre.
2. des stagaires competents qui cherchent un stage dans le logiciel libre ou a defaut un stage dans une ambiance de travail raisonnablement sympa.
Ce serait dommage de se rater, que je trouve un stagiaire qui n'aime ni python, ni Qt et que les passionnes de logiciels libres trouvent uniquement un stage ou il faut developper en asp.NET . Donc j'ai prefere poste ce journal au cas ou.
T'en connais beaucoup des stages ou tu fais du logiciel libre ? T'en connais beaucoup des stages ou tu peux faire du python ? du Qt ?
Un autre facon de voir la chose, c'est est-ce que t'as deja travaille dans une boite normale, avec des lobotomises de chez Microsoft ? J e peux te dire pour l'avoir fait que ce n'est pas la joie. Au moins chez nous, on peut discuter tranquillement des trolls du moment (novellcapueyapukde) dans une ambiance detendue.
A noter aussi que le savoir-faire que tu peux accumuler durant ce stage est utilisable directement dans des projets logiciels libres populaires : python, Qt.
[^] # Re: ouai
Posté par Philippe F (site web personnel) . En réponse au journal Les informaticiens précoces. Évalué à 1.
[^] # Re: Qt
Posté par Philippe F (site web personnel) . En réponse au journal .Net vs Qt vs Java. Évalué à 4.
[^] # Re: Il manque des trucs tout de même
Posté par Philippe F (site web personnel) . En réponse à la dépêche OpenOffice 2.0. Évalué à 3.
[^] # Corp de texte et standard
Posté par Philippe F (site web personnel) . En réponse à la dépêche OpenOffice 2.0. Évalué à 1.
[^] # Re: Cela rassure
Posté par Philippe F (site web personnel) . En réponse à la dépêche Rendre GNOME rapide. Évalué à 4.
Cette histoire de glist en O(n2) est quand meme pathetique. C'est pas comme si on decouvrait un nouveau truc. On est en 2005, ca fait des annees qu'on connait des algorithmes et des heuristiques d'optimisations de liste. Optimiser une gestion de liste, c'est un exercice d'etudiant de 1e annee d'informatique. Se dire que l'un des meilleurs bureaux graphique de la planete en est encore la, ca fait peur.
Si tu regardes l'historique de glist, tu vois que ca n'a jamais pratiquement bouge. D'un cote, c'est bon signe, ca veut dire qu'elle a satsifait tous les besoins depuis des annees sans modification. Mais si tu regardes du cote de Qt, tu vois que au fil des ans, il y a eu pas mal de reflexion autour de la bonne facon d'optimiser une qlist.
Ca fait des annees que KDE se soucie de l'optimisation (la liste kde-optimize etant un symptome, creee en 2002), a cause de son image de bloatware. Quand je vois le niveau des mecs qui y poste d'ailleurs, je me sens tres tres humble.
Pour rappel, des trucs comme le prelinking ont ete inventes par des mecs de KDE, pour resoudre des problemes de performance du chargeur de lib de linux.
[^] # Re: Qq liens en +
Posté par Philippe F (site web personnel) . En réponse au journal Openoffice 5 ans !. Évalué à 3.
Pas tres stable pour les feuilles de calculs avec des liens vers d'autres feuilles, mais plutot sympatique dans l'ensemble.
[^] # Re: Port sous Windows ...
Posté par Philippe F (site web personnel) . En réponse à la dépêche Les nouvelles de KDE. Évalué à 2.
[^] # Re: Port sous Windows ...
Posté par Philippe F (site web personnel) . En réponse à la dépêche Les nouvelles de KDE. Évalué à 2.
C'est marrant, je connais des gens qui y passent beaucoup de temps et d'energie. Une annonce dans le new york times, j'ai du rever. Ou spreadfirefox, ca n'existe pas.
> Le libre qui aurait pu (qui pourrait encore) concretiser une belle utopie
Et toi, tu fais quoi a part raler ?
[^] # Re: DBus?
Posté par Philippe F (site web personnel) . En réponse à la dépêche Les nouvelles de KDE. Évalué à 4.
Ce qui est dommage, c'est que des mecs super comme Mickael Meeks aie passe autant de temps sur une techno qui sera jetee a la poubelle.
[^] # Re: DBus?
Posté par Philippe F (site web personnel) . En réponse à la dépêche Les nouvelles de KDE. Évalué à 5.
freedesktop rassemble des hackers des differents desktop pour en faciliter l'interoperabilite. Freedesktop fait avant tout des standards, et propose en general une implementation de reference (DBUS).
Freedesktop emerge d'une necessite, celle de discuter interoperabilite en terrain neutre. Freedekstop n'a aucun pouvoir en dehors de celui des hackers individuels qui sont d'accord avec une proposition de freedesktop.
Pour DBUS dans KDE, l'idee semble faire son chemin mais c'est pas encore gagne. Ce qui est sur, c'est qu'il y aura un pont DBUS - DCOP de facon a conserver la compabilite.
[^] # Re: mail
Posté par Philippe F (site web personnel) . En réponse à la dépêche Sortie de Bugzilla 2.20 (et 2.21.1 et 2.18.4). Évalué à 1.
[^] # Re: numéros de version
Posté par Philippe F (site web personnel) . En réponse à la dépêche Actualités Firefox, Thunderbird, Mozilla et SeaMonkey. Évalué à 3.
[^] # Re: hé, Antoine?
Posté par Philippe F (site web personnel) . En réponse au journal Yahoo, Google et autres pourris. Évalué à 2.
Une fois que ces boites s'installent sur place, elles ont deux choix :
1. lutter de toute leur force pour le respect des droits de l'homme et s'opposer a l'autorite chinoise
=> elles vont se faire tout simplement interdire et donc echoueront a leur objectif commercial.
2. accepter les regles antidemocratiques locales en fournissant leur service.
A noter que 2. est peut-etre plus utile que 1. Que vaut-il mieux un moteur de recherche censure, mais puissant et capable de trouver des pages peut-etre difficiles a trouver ou pas de moteur de recherche du tout ?
Meme si les boites dont on parle respectent le non-respect des droits de l'homme et censurent leurs resultats, il peut y avoir d'autres moyens plus discrets de lutter. Etre un excellent moteur de recherche permettant de trouver facilement des proxy caches ou des pages de protestation sur la Chine en est un.
# Super initiative
Posté par Philippe F (site web personnel) . En réponse à la dépêche Wikipédia-party à la Cité des sciences de La Villette. Évalué à 2.
[^] # Re: Bazaar
Posté par Philippe F (site web personnel) . En réponse à la dépêche Des nouvelles des gestionnaires de versions GNU Arch et Bazaar. Évalué à 2.
Il y a des gens qui se disent que si le kernel utilise un truc, c'est forcement le meilleur truc au monde. C'est a moderer fortement, les hackers du kernel n'etant pas des etres humains normaux, mais des hackers du kernel.
> Aucun des programmes que tu cites ne répondent à tous tes critères.
Ce sont des criteres en vrac. De fait, mon argumentation est justement qu'il n 'y a pas de SCM universel pour l'instant.
Dans ma boite mes deux commerciaux utilisent CVS quotidiennement sous windows grace a tortoise CVS. Ca ne serait possible ni avec arch, ni avec git, ni avec tla. Subversion serait envisageable. Malgre tous les inconvenients de CVS, c'est de loin une des meilleurs solutions par rapport a mon besoin.
J'ai oublie d'ailleurs dans mes criteres la facilite d'utilisation. CVS, un utilisateur utilise quotidiennement deux commandes : commit update. Rien qu'en voyant la page de man de git, je laisse tomber. Il va me falloir deux heures pour comprendre de quelles commandes j'ai besoin et lesquelles ne me servent a rien.
Et puis niveau stabilite, si la porcelaine evolue, ca ne convient peut-etre pas a tout le monde.
J'ai regarde le mode pack mais j'ai pas trouve de description de l'operation de packing qui est faite derriere. Je ne peux donc pas dire si c'est efficace ou pas comme methode de stockage.
[^] # Re: A ce sujet...
Posté par Philippe F (site web personnel) . En réponse à la dépêche Des nouvelles des gestionnaires de versions GNU Arch et Bazaar. Évalué à 2.
Dit autrement:
- avec subversion/CVS, tu peux avoir un admin a temps partiel
- avec ClearCase, il te faut deux admin a temps plein
[^] # Re: Bazaar
Posté par Philippe F (site web personnel) . En réponse à la dépêche Des nouvelles des gestionnaires de versions GNU Arch et Bazaar. Évalué à 6.
Quelques points notables:
- git stocke les fichiers integralement. Si tu changes une ligne a fichier texte de 50000 lignes, git restocke le fichier texte. CVS et consorts stockent un diff. Donc en terme de stockage, git n'est pas efficace et ce n'est pas son but.
- git est concu pour avoir une notion de tracabilite tres profonde, sur l'integralite des sources et des changements d'un projet, le tout valide par une signature cryptographique (SHA). Il est possible en une seule operation de savoir si deux jeux de source git sont identiques ou differents.
- git est optimise pour la notion de partage et de melange d'arbres differents, qui correspondent au modele de developpement du noyau : beaucoup de developpeurs avec des branches partielles (sous-systemes, experimentales) font d'abord des modifs dans leur branche avant de faire remonter la modif vers le repository de Linus.
Bref, pas grand chose a voir avec les besoins classiques d'un SCM :
- versionnement des fichiers
- remonter dans le temps sur les versions passees
- notion de branche
- notion de marquage (tag)
Apres, on peut rajouter d'autres fonctionnalites :
- commit atomiques
- renommage
- utilisation en mode completement decentralise facon arch
- interface conviviale
- compacite du stockage
- facilite de deploiement
- portabilite
- nombre d'outils et frontend associes
- stabilite
- dispoinbilite d'un frontend sous windows
qui font qu'on aboutit a CVS, Monotone, subversion, arch, tla, bazaar, bazaar-ng, Super CVS et autres.
Je sais que dans ma boite precendent, la convivialite etait un element fondamental. Si l'outil n'etait pas convivial, les developpeurs ne l'utilisaient pas et continuaient avec leurs zip sur un serveur partage. Chaque usage a ses criteres particuliers.
Pour Linus, c'est git.
[^] # Re: Une roadmap pour KDE4 ?
Posté par Philippe F (site web personnel) . En réponse à la dépêche The aKademy 2005 à Málaga. Évalué à 4.
Les avantages que tu cites d'ailleurs ne sont pas la pour offrir une bonne "scriptabilite" ( = capacite d'etendre et de controler une application par script ) mais un bon environnement de developpement.
KDevelop supporte deja d'autres langages que Ruby, et ruby est loin d'etre le seul langage a faire du dcop ou du soap.
Ruby va avoir une place confortable en terme d'IDE en effet, car Richard Dale, le M. Binding de KDE aime beaucoup ruby. Mais l'approche utilisee pour integrer les langages de scripts dans KDE est generique, et il y a des supporters d'autres langages dans KDE.
Tu peux lire le blog de Ian Geiser pour voir par exemple tout ce qui est fait pour le javascript avec KJSEmbed :
http://www.kdedevelopers.org/blog/2(...)
[^] # Re: Une roadmap pour KDE4 ?
Posté par Philippe F (site web personnel) . En réponse à la dépêche The aKademy 2005 à Málaga. Évalué à 7.
Pour repondre a tes questions :
- du multithreading : il y a deux presentations sur les possibilites de faire des applications asynchrones et/ou multithreadees et toutes les deux ont semble-t-il bien marche. Donc il va y avoir une meilleure comprehension de ce qu'on peut faire en asynchrone. C'est pas pour ca qu'on va re-ecrire kdelib en multithreads.
- c'est quoi les _nouveaux_ standards de freedesktop ? KDE utilise deja la plupart des standards definis dans le cadre de freedesktop. Et participe a l'elaboration des futurs standards. Pas de revolution de ce cote-la, mais le travail de KDE s'inscrit dans la continuite.
- nouvelles applications : j'ai pas entendu parle de killer app. Cependant, ca fait plusieurs annees que Krita est developpe et il semble arriver a maturite. Il semble aussi qu'on se dirige vers un multi-viewer a base de KPdf. Il y a aussi la convergence de developpeurs, d'artistes et d'ergonomes dans le cadre du projet Appeal, avec notamment un nouveau bureau plus interactif.
Il semble aussi que la scriptabilite passe au premier plan dans KDE 4. Je n'y suis pas mais j'ai lu pas mal de gens discuter de facon d'introduire une interface de script generique au coeur des libs KDE, accessibles a divers langages de scripts : ruby, python et javascript au moins.
Globalement, il faudra attendre quelques mois pour comprendre tout l'impact de l'akademy 2005 mais il semble que ca soit bien parti.
[^] # Re: RC != deverminage
Posté par Philippe F (site web personnel) . En réponse à la dépêche Sortie du noyau Linux 2.6.13. Évalué à 7.
Pour comprendre ce que j'appelle lisible et propre, il suffit de regarder la facon dont fonctionne KDE ou Mozilla. Il n'y a pas 24 numero de versions, et les versions en dev s'appellent beta, alpha ou autre, les versions super stables ont un no de release unique, et les versions presque stables avant la release sont notes RC.
On peut suggerer a Linus que les versions dont les 4 chiffres sont multiples d'un meme nombre premier sont stables, celles ou la sommes des 4 chiffres est divisible par 7 sont des release candidate, et les autres sont instables. Ca me paraitrait a peu pres aussi lisible que le systeme actuel.
[^] # Re: deverminage
Posté par Philippe F (site web personnel) . En réponse à la dépêche Sortie du noyau Linux 2.6.13. Évalué à 5.
Ce que confirme au moins partiellement wikipedia:
http://en.wikipedia.org/wiki/Computer_bug(...)
# RC != deverminage
Posté par Philippe F (site web personnel) . En réponse à la dépêche Sortie du noyau Linux 2.6.13. Évalué à 10.
Les RC, etant des candidats finaux, ne servent pas a deboguer mais a tester que tout marche, ce qui n'est pas du dout a mon sens la meme demarche. Apres, il peut y avoir des vermines [1] dans une version, qui doivent evidemment etre corrigees mais ce sont en theorie de vermines mineures.
La phase de deverminage a lieu normalement pendant le developpement de nouvelles fonctionnalites, c'est a dire bien en amont de la phase des RC.
[1] : j'avoue que j'ai quand meme du mal a ne pas appeler ca un "bug".