Le fait d'avoir fait une incursion dans un autre paradigme de programmation te permettra d'avoir plus de solutions dans ta boite a outils du programmeur. Tu verras qu'un jour, ca fera la difference chez un client.
Genre un jour, tu vas tomber sur un projet. Tu vas commencer a te prendre la tete avec des objets et de l'heritage et tout d'un coup, l'illumation te viendra: c'est un probleme qui doit se resoudre avec une approche beaucoup plus fonctionelle. Meme si tu codes au final la solution en C++, tu utiliseras des techniques de programmation fonctionelle qui te donneront une solution plus elegante qu'une solution en style objet.
C'est pour ca que c'est important d'avoir touche a OCaml.
Si tu vas voir la page du "Great Language Shootout", tu verras que OCaml a le meilleur score dans de nombreuses configurations.
Meme si je n'en ai pas fait beaucoup, ce que j'ai aime dans ce langage, c'est l'inference de type. Alors que python introduit des bugs subtils et indectables par sa resolution dynamique des attributs, OCaml a une approche hyper clean qui te permet de trouver des problemes subtils tres tot dans le cycle de dev. Et surtout, il ne te force pas la main sur les types (contrairement au C++ ou a Ada ou tu dois vraiment _tout_ dire) mais se debrouille lui-meme pour deduire des infos que tu lui as fourni, les types qui sont utilises.
Comme d'habitude, a chaque fois que je lis des docs sur le Hurd, je reste sur une impression tres mitigee.
Ce truc a tres peu d'applications pratiques. Un des avantages de Linux, et ce qui l'a tres vite distingue de minix, c'est qu'il est utile concretement. A cote de ca, Hurd reste un exercice de style.
Le fait est qu'un noyau reste un truc pour gerer du materiel. Mon impression est que Hurd veut reussir a abstraire completement cette partie, et que ca donne des resultats sous-optimaux, comme les problemes qu'il decrit avec la gestion de la memoire. Autant je pense qu'on peut faire abstraction de beaucoup de choses au niveau langage de programmation, autant je ne suis pas persuade que ca s'applique aussi bien a un OS (meme si PDP11 faisait des merveilles avec sa macine lisp, il parait).
Deporter la gestion de la memoire du cote des applications. Super! J'essaie de reflechir a quelle application de nos jours aurait besoin de sa propre gestion memoire. Ce serait soi des applications avec des besoins de tres grosses quantites, soit des applications avec des besoins de beaucoup de petites quantite (ce qui pousse parfois a re-ecrire son gestionnaire de memoire, le modele classique etant plutot adapte a des allocations de gros blocs de facon non repetees). Je suis curieux de savoir si dans la pratique, c'est super lourd a gerer ou s'il suffit juste de linker avec libmemory et ca marche tout seul.
Je pense aussi aux remarque d'Alan Cox, sur l'obsolescence du modele Hurd en tant que station de travail. Hurd est oriente serveur avec plusieurs utilisateurs, ce qui etait l'environnement classique de travail de l'epoque ou il a ete concu. Aujourd'hui, avec des postes PC mono-utilisateurs tout puissants, qui a besoin de monter son systeme de fichier en mode utilisateur ?
Ca n'enleve rien a la qualite du travail effectue, c'est juste que un peu comme quake en ascii-art, ca reste un exercice de style.
Oui, unsermake est deja utilise mais ton commentaire est tout a fait pertinent. unsermake ne fait que simplifier une des 12 etapes qui genere les makefile de KDE.
Le but de se debarasser d'autotools, c'est probablement de passer de 12 etapes a 2, et de beneficier en sus d'ameliorations de performances diverses au niveau de la compilation.
Je ne connais pas bien le sujet, mais j'ai entendu dire que le fait que make n'est qu'une vision repertoire par repertoire rend pas mal d'optimisations (distribution de la compilation, blocage de certains morceaux de la compilatino, ...) plutot difficiles.
La fonctionnalite qui me plait le plus avec subversion, c'est qu'on peut faire un diff de facon instantanee, sans avoir une connexion avec le serveur.
Les astucieux auront tout de suite note que cela signifie que tous les fichiers sont en double en local: version modifiee et version non modifiee. Ca prend donc deux fois plus de place, mais les fichirers texte ne prennent pas beaucoup de place.
A cote de ca, c'est _super_ pratique de pouvoir annuler ses changements rapidement, ou bien de regarder ce qu'on a change en une seconde.
Disons que vue la complexite d'autotools, je passe moins de temps a faire un support en live pour des config exotiques qu'a essayer de faire marcher ce bousin.
Pour te repondre, je te redonne un bon dicton d'informaticien: "Il ne faut pas reinventer la roue. Sauf quand le premier inventeur a invente une roue carree".
autotools, c'est clairement une roue carree. C'est un arrachage de cheveux a maintenir. Parmis les milliers de contributeurs et parmi la quarantaine de developpeurs principaux de KDE (qui ont un sacre niveau en informatique), il y a en tout et pour tout deux developpeurs qui comprennent completement le systeme des autotools utilise par KDE et qui sont capables de le maintenir. Ca ne fait pas beaucoup.
Les developpeurs de KDE ne prennent pas des decisions techniques a la legere. Si ils se debarrassent d'autotools, c'est que ce n'etait plus gerable.
Il y a des super projets pour remplacer autotools, qui ont tous la caracteristiques d'etre simple a utiliser et simple a faire evoluer. Deux qualite qui manquent terriblement a autotools. Je peux te dire que le type qui s'occupe d'autotools pour KDE (il me semble que c'est Stephan Kulow) est super motive pour utiliser autre chose, pour te donner une idee du truc.
Scons semble etre une alternative interessante. Il y en a d'autres. Pourquoi se prendre la tete avec un systeme super complexe quand des alternatives plus simples existent.
Faut pas etre trop sentimental. Autotools etait une bonne solution au moment ou il a ete cree, mais aujourd'hui, l'outil ne fait plus le poids. Avoir python ou perl installe sur sa machine n'est pas une contrainte extraordinaire alors qu'a l'epoque ou autotools a ete cree, sh etait la seule dependance acceptable.
Par exemple, je suis toujours choque que ./configure ne detecte pas les erreurs de syntaxes dans ses options:
./configure --enable-truc-muche ne te renverra aucune erreur. Sauf que en fait, il fallait taper:
./configure --enable-trucmuche
Et encore, ca c'est un probleme mineur d'utilisateur, rien a voir avec la complexite de la mise en place du truc.
Peut-on savoir les raisons de ce rejet de KDE aussi categorique ? Tu as un probleme avec la GPL ?
Sinon, je suis d'accord avec toi sur le fonctionnement global. Je suis passe de kmail a thunderbird et c'est l'horreur. Non content de gerer des comptes separes, il gere aussi les filtres separement. Je cherche encore le jour un un message envoye a la mailing list trucmuche doit etre filtre differamment suivant qu'il est arrive sur le compte X ou le compte Y. Sans compter que ca cree des bugs subtils sur thunderbird. Tu ne peux pas filtrer ton inbox global, quand tu affiches les filtres, il n'y a en fait que la moitie des filtres qui sont affiches, etc etc.
Je ne comprends pas du tout la raison de cette conception ou le compte individuel de mail prevaut sur la simplicite.
Un conseil: n'apprend jamais autoconf et automake. Tu perdras plus de temps a les utiliser qu'a developper du soft. A la place, apprends un truc super simple et qui a un vrai futur, comme scons ou qmake (pour les petits projets).
Va voir du cote des sujets de l' IFPC (International Functional Programming Contest), il me semlbe qu'il y avait quelques exercices interessant ou l'ecriture d'un compilateur etait un plus.
Sinon, quitte a ecrire un langage, fait leur ecrire un langage qui leur apprend aussi des notions de qualite logicielle. Genre un langage prouvable, ou bien un langage a la eiffel, avec pre et post-assertion, ou bien un langage comme Ada, ou tous les intervalles de donnes sont parfaitement controlle.
L'idee etant de trouver un langage avec des caracteristiques plus robuste que la moyenne de ceux qu'ils manipulent (C etant le pire).
Maintenant, j'aimerai voir une alternative qui est aussi simple a gerer.
J'ai un besoin extraordinairement normal: je veux un index a gauche qui donne acces a toutes les pages de mon site web sur la droite. La solution frame est la seule solution simple qui permette de faire ca sans dupliquer l'index sur chacune des pages. Si j'ai un index de 20 pages et que je rajoute un lien, je ne veux pas mettre a jour 20 pages de contenu.
J'avais souleve le probleme avec Tristan Nitot il me semble, et il n'avait pas de solution a me proposer.
Si tu ne veux pas passer par des cadres, il te reste soit du scripting cote serveur (super lourd), soit faire des template que tu dois pre-processer avant de les transformer en html.
Bref, si t'es pas geek, la maintenabilite d'un site avec index est une gagure, a moins d'utiliser des trames.
Si je ne me suis pas exprime clairement, tu peux aller voir mon site http://phil.freehackers.org(...) (site tout pourri et pas valide, je sais) qui montre ce que je veux avoir. Index a gauche, titre en haut, contenu a droite.
Je suis d'accord et j'irai meme plus loin. Faire une licence pour son logiciel libre est debile, pour un probleme de compabilite. Ca veut dire que tu ne pourras jamais integrer du code sous une autre licence, et qu'en general aucun code de ton logiciel ne pourra etre integre dans un autre logiciel. A moins de mettre ton soft sous plusieurs licences, mais dans ce cas, quel est l'interet de faire une licence speciale ?
Mozilla et Apache ont leur propre licence d'une part pour des questions d'ego (a mon avis) et aussi parce que leurs juristes se sont penches sur la GPL et ont dit qu'il y avait les problemes X et Y, qu'ils ont essaye de resoudre via leur nouvelle licence.
Meme avec les problemes de licence que des juristes peuvent imaginer sur la GPL, la LGPL ou la BSD, cela vaut mieux a mon avis qu'une licence maison, pour des raisons d'interoperabilites entre licence.
<< Mais ça fait depuis le début de bonobo (en fait le début de Gnome) que les gens critiquent Orbit/Corba/bonobo et prévoit sa suppression à court terme. >>
Ouai, ca se peut. Ils doivent etre assis en face de ceux qui predisent depuis le debut de KDE que le projet va se planter:
- parce qu'il est base sur un toolkit proprietaire (KDE 1)
- parce qu'il n'utilise pas Corba (KDE 2)
- parce que Sun, Redhat, IBM, Ximian, etc investissent a fond dans Gnome et vont rendre KDE obsolete.
Finalement, il faut pas trop ecouter les racontars...
<< Pour ajouter un élément "technique", bonobo n'a rien à voir avec dlopen. >>
Oui et non. Il est possible de faire tourner les composants bonobo a l'interieur du meme processus, et dans ce cas, c'est bien un dlopen qui est utilise.
Ce que je disais, c'est que l'equivalent cote KDE de bonobo, c'est KPart + DCOP. KPart utilise dlopen ce qui le rend leger, facile a comprendre, facile a lancer (pas de fork comme en corba) et qui a permis aux composants KPart de se developper tres vite.
Le choix de corba dans bonobo rend la technologie plus complexe et limite par consequent son adoption.
J'me fais vieux la. Va falloir que je renouvelle mes trolls.
Bon aller, en toute honnetete, j'ai vu un des derniers Gnome a linux solution et j'ai ete impressionne. J'ai trouve ca tres poli, tres clair. Apres, faut voir ce que ca donne a l'usage mais l'impression generale etait plutot positive.
C'est juste dommage que, non allez, je m'arrete la. Bonne chance pour le projet, il y a des gens vraiment brillant qui bossent dessus (qu'on retrouve sur xdg).
Je me marre en lisant les problemes que rencontre l'utilisation de bonobo chez les developpeurs. C'est pour ce genre de raison que KDE a mis mico (le corba utilise a l'epoque pre-KDE 2) a la poubelle il y a quelque chose comme 5 ans. Ils ont remplace des mois de travail sur corba par 1 semaine - homme de dev et un dlopen. Mais bon, tout le monde peut continuer a croire que bonobo, c'est l'avenir de Gnome.
Je pense que le probleme de fond de bonobo, c'est que Corba est beaucoup trop complexe pour les besoins qu'en ont Gnome. Quand on a affaire a des gens qui travaillent pendant leur temps libre, mieux vaut eviter de leur compliquer la vie. A cote, KPart fournit les memes services que bonobo, mais ca a coute une semaine de dev et n'importe quel debutant motive peut comprendre comment ca marche en moins d'une semaine (man dlopen suffit en gros).
Merci pour ces conseils marketing non eclaires, je sais que ca part d'une bonne intention.
Ca fait 6 ans que je suis dans le secteur, et 2 ans que j'etudie le marche de tres pres donc je sais comment me positionner.
Aujoud'hui, la pression sur ce marche se fait uniquement par les prix. Quand tu fabriques 10 millions ce cartes, chaque centime compte. Nous avons un positionnement bas-cout et c'est ce qui fait la force de notre solution. C'est tout. Et gemplus ne peut pas aller trop nous chercher du cote des prix car ils ont leur propres problemes, par exemple le fait qu'ils doivent remplire leurs usines.
<< Car entre 2 produits proprios, on choisira toujours le plus connu et celui avec la plus grosse boite derrière (qui peut en outre se permettre de régulièrement casser les prix pour tuer ses petits concurents).
>>
C'est vrai si les deux produits proprio sont strictement equivalents. Ce n'est pas le cas, grace a des choix techniques intelligents, on propose des prix qui sont 3 a 4 fois inferieur a ce que fait Gemplus ou Axalto (ex Schlumberger). Autant te dire que ca joue beaucoup. A cote de ca, le client se contrefout de savoir si notre produit est open source ou pas, du moment qu'on est certifie Visa ou certifie pour de la securite (EAL).
Le client gere la perennite avec au moins un double-sourcage sur l'OS (dans le marche qui m'occupe en ce moment, il y a un quadruple sourcage). L'open source dans notre cas n'assure pas du tout la perennite car il y a des couts de fabrication et de certification redhibitoire. Meme si les sources pouvaient etre entierement publique (ce n'est pas le cas, il y a des restrictions legales sur les composants), il faudrait couter environ 100 000 euro de cout de fabrication pour reprendre notre produit et en faire une carte. Ajoutes a cela des ingenieurs, des commerciaux plus la maitrise du produit, tu vois qu'il y a un cout considerable de reprise du produit. Il est beaucoup plus facile de demander a un concurrent un produit avec les memes caracteristiques. En plus, le client ne pourrait pas se lancer dans une telle operation, il doit rester strictement independant des fournisseurs d'OS.
Il faut bien comprendre que chaque type de marche a des regles de fonctionnement qui sont differentes, et qui font qu'un raisonnement qui est vrai pour un marche a la mysql ne s'applique pas forcement dans d'autres perspectives.
Bla bla bla <= tu sors des arguments hyper generiques sans te pre-occuper de la question precise.
Desole de te decevoir, mais je fais du libre pour des raisons morales (partage global de la connaissance) et pour le fun. Pour l'instant, le libre ne m'a rien rapporte economiquement et je n'ai pas l'impression que ca va changer.
C'est vrai qu'une carte a puce avec du code en ROM sera vachement plus perenne si le produit est en open source. Surtout quand il est legalement impossible de fournir la totalite du code source (parties liees aux composant qui sont sous NDA). Donc dans ce cas precis, le libre n'apporte aucune perennite.
Ca fait 10 ans que je fais du logiciel libre, j'ai bien reflechi a la question avant de lancer cette boite.
Comme je l'ai dit, on a meme fait un projet logiciel libre qui ne nous a rien rapporte, si ce n'est que nos sources sont sur le web et que les chinois peuvent maintenant faire un produit concurrent si ils "oublient" de respecter la licence.
<< le code est propre, on ne fait pas n'importe quoi >>
On propose des audits de code a nos clients et les certifications securitaires compreennent egaglement un audit de code. Cela dit, ca n'empeche pas de faire n'importe quoi, et cela vaut aussi pour les projets libres. Le fait que le code soit libre n'empeche pas les developpeurs de coder comme des cochons si c'est comme ca qu'ils travaillent.
Les journaux sont censes ne parler que de Linux et de logiciel libre ? Il me semblait qu'on avait le droit de parler de sa vie.
En fait, je ne cherche pas vraiment des developpeurs (meme si je ne cracherai pas dessus, soyons honnete) mais j'avais surtout envie de partager ca ici. Reussir a mener une boite jusqu'au point ou tu as besoin de recruter parce que le chiffre d'affaire commence a avoir une pente lineaire positive, voire exponentielle, c'est vraiment une etape tres importante pour moi.
Voila, le rapport avec Linux, c'est moi: j'utilise linux, je fais du logiciel libre, j'en mange, j'en dors mais je n'en vis pas.
Ton salaire ? On en discute lors de l'entretien :-))
Ma boite ne peut pas me payer mais ca ne pose pas de probleme parce que je suis encore paye par les assedics (pour info, le gouvernement sponsorise la creation d'entreprise mieux que tous les business angel des etats-unis). En revanche, j'ai du travail et un peu de treso pour deux personnes de plus. Et ces deux personnes supplementaires devraient pouvoir generer suffisamment de revenu pour me payer mon salaire a moi (qui sera largement au dessus du smic, faut pas deconner quand meme).
Donc vous affoler pas, on paye les ingenieurs a un tarif raisonnable.
Ouai, ca marche dans le cas de soft pur. Dans mon cas, une fois qu'on a le soft, il faut compter 30 000 euro pour passer a la realisation de la carte. Ces 30 000 euro ne sont pas open source et doivent etre fourni longtemp avant le premier revenu tire du produit ou du service. Donc avec un modele open source, je peux aller me rhabiller.
C'est le meme probleme que pour les CPU libres. Il y a des couts enormes de fabrication, qui ne peuvent pas etre couvert par le modele open source. Une societe deja etablie peut se permettre de faire un invstissement la-dessus, en se disant qu'elle se rattrapera plus tard. Pas une societe en demarrage comme la notre.
Quel est l'interet d'avoir un logiciel open source non telechargeable ? L"interet de l'open source, c'est de developper une communaute de contributeurs. Si ils ne peuvent pas telecharger, ta communaute est reduite strictement a tes clients. En imaginant qu'un de tes clients soit un developpeur motive, quel est l'interet pour toi de l'autoriser a republier le source ? Autant lui faire une licence qui lui donne le droit de modifier le produit dans le cadre de ses besoins internes et puis basta.
TheKompany a fait des logiciels open source non telechargeable. Non seulement, ils se sont mis a dos une partie de la communaute (quoi, c'est pas telechargeable) mais en plus, ils n'ont eu aucun contributeur. Et le produit n'est pas top. Bref, le bide complet.
Je me place dans un logique economique pure: Avec quoi je gagne de l'argent sur mon logiciel ?
1. formation
2. maintenance
3. installation
4. developpements specifiques
Comment maximiser mes revenus ?
1. en faisant des logiciels tres difficiles a utiliser
2. en faisant des logiciels bugges necessitant beaucoup de maintenance
3. en faisant des logiciels difficile a installer, pour qu'on soit obliger de faire appel a moi pour une installation
4. en faisant des logiciels incomplets pour que me demande des evolutions.
CQFD.
Vous avez remarque, je viens de decrire le modele commercial de SAP. Certains disent que c'est aussi le modele de Motif.
Note que si tu fais un produit grand-public que tu vends, tu as interet au contraire a minimiser 1,2,3 et 4, de facon a genere le maximum de satisfaction et a faire decoller tes ventes.
Bon, donc heureusement que les logiciels libres sont developpes dans une optique qui n'est pas purement commerciale, que les developpeurs ont en general l'amour du travail bien fait, et surtout, que les choses sont deja suffisamment compliquee pour qu'on aie pas besoin d'en rajouter pour generer des revenus avec 1,2,3 et 4.
> Si tu ne fais QUE ton « truc complet phare », tu n'as pas beaucoup d'autres choix que de faire du proprio, puique tu n'as aucun revenu à côté.
Tout a fait. Donc si tu veux developper un produit qui te coute environ 4 annees hommes, tu peux faire le choix de passer 2 ans a 2 pour le developper et de le vendre ensuite (c'est ce que j'ai fait). Mais tu ne peux pas le donner.
Avec un modele mixte, il faut que j'assure mes revenus au minimum. Donc en admettant que je m'en sorte tres bien et que je bosse a mi-temps, il nous faudra 4 ans pour faire le meme produit. Pas de bol, dans 4 ans, ce produit n'aura bien rien d'innovant et aura perdu tout son interet commercial. A ce moment-la, je n'aurai plus qu'a fermer boutique.
En plus, des que ce n'est pas un projet ou il y a beaucoup d'utilisateurs, (comme apache), c'est tres dur d'attirer des developpeurs. On a developpe notre OS pendant un an en open source. On a eu _zero_ contributeurs. D'ailleurs, tu peux aller voir : http://jayacard.sf.net(...)
Donc finalement, j'ai beaucoup a perdre et tres peu a gagner en mettant ce projet en open source.
> Il y a de nombreux exemples, Qt de Trolltech, tous les outils d'installation et de config de mandrake, Dolibarr, NVU, et combien d'autres...
Il y a quelques exemples. Qt etant le plus impressionnant. Dolibarr, je ne connais pas. Les outils d'installe de mandrake sont open source parce que mandrake a d'autres sources de revenu qui financent leur developpement.
En dehors de Qt, il y a ACT qui fait un produit open source qui est aussi vendu, et qui leur sert reellement a assurer leurs revenus. A ma connaissance, ce sont les seuls societes qui vivent de la _vente_ d'un produit open source qu'elles ont developpe elles-meme.
[^] # Re: Pérénité
Posté par Philippe F (site web personnel) . En réponse à la dépêche Présentation d'OCaml à Rennes le jeudi 7 avril, 20h, MCE, 48 bd Magenta. Évalué à 2.
Genre un jour, tu vas tomber sur un projet. Tu vas commencer a te prendre la tete avec des objets et de l'heritage et tout d'un coup, l'illumation te viendra: c'est un probleme qui doit se resoudre avec une approche beaucoup plus fonctionelle. Meme si tu codes au final la solution en C++, tu utiliseras des techniques de programmation fonctionelle qui te donneront une solution plus elegante qu'une solution en style objet.
C'est pour ca que c'est important d'avoir touche a OCaml.
Si tu vas voir la page du "Great Language Shootout", tu verras que OCaml a le meilleur score dans de nombreuses configurations.
Meme si je n'en ai pas fait beaucoup, ce que j'ai aime dans ce langage, c'est l'inference de type. Alors que python introduit des bugs subtils et indectables par sa resolution dynamique des attributs, OCaml a une approche hyper clean qui te permet de trouver des problemes subtils tres tot dans le cycle de dev. Et surtout, il ne te force pas la main sur les types (contrairement au C++ ou a Ada ou tu dois vraiment _tout_ dire) mais se debrouille lui-meme pour deduire des infos que tu lui as fourni, les types qui sont utilises.
[^] # Re: Bravo
Posté par Philippe F (site web personnel) . En réponse à la dépêche talweg, solution de portail captif. Évalué à 2.
C'est monte comment leur systeme ?
# Mouai
Posté par Philippe F (site web personnel) . En réponse à la dépêche Interview de Marcus Brinkmann, développeur du Hurd. Évalué à 4.
Ce truc a tres peu d'applications pratiques. Un des avantages de Linux, et ce qui l'a tres vite distingue de minix, c'est qu'il est utile concretement. A cote de ca, Hurd reste un exercice de style.
Le fait est qu'un noyau reste un truc pour gerer du materiel. Mon impression est que Hurd veut reussir a abstraire completement cette partie, et que ca donne des resultats sous-optimaux, comme les problemes qu'il decrit avec la gestion de la memoire. Autant je pense qu'on peut faire abstraction de beaucoup de choses au niveau langage de programmation, autant je ne suis pas persuade que ca s'applique aussi bien a un OS (meme si PDP11 faisait des merveilles avec sa macine lisp, il parait).
Deporter la gestion de la memoire du cote des applications. Super! J'essaie de reflechir a quelle application de nos jours aurait besoin de sa propre gestion memoire. Ce serait soi des applications avec des besoins de tres grosses quantites, soit des applications avec des besoins de beaucoup de petites quantite (ce qui pousse parfois a re-ecrire son gestionnaire de memoire, le modele classique etant plutot adapte a des allocations de gros blocs de facon non repetees). Je suis curieux de savoir si dans la pratique, c'est super lourd a gerer ou s'il suffit juste de linker avec libmemory et ca marche tout seul.
Je pense aussi aux remarque d'Alan Cox, sur l'obsolescence du modele Hurd en tant que station de travail. Hurd est oriente serveur avec plusieurs utilisateurs, ce qui etait l'environnement classique de travail de l'epoque ou il a ete concu. Aujourd'hui, avec des postes PC mono-utilisateurs tout puissants, qui a besoin de monter son systeme de fichier en mode utilisateur ?
Ca n'enleve rien a la qualite du travail effectue, c'est juste que un peu comme quake en ascii-art, ca reste un exercice de style.
[^] # Re: pourquoi virer autotools ?
Posté par Philippe F (site web personnel) . En réponse à la dépêche KDE 3.4 officiellement sorti. Évalué à 2.
Le but de se debarasser d'autotools, c'est probablement de passer de 12 etapes a 2, et de beneficier en sus d'ameliorations de performances diverses au niveau de la compilation.
Je ne connais pas bien le sujet, mais j'ai entendu dire que le fait que make n'est qu'une vision repertoire par repertoire rend pas mal d'optimisations (distribution de la compilation, blocage de certains morceaux de la compilatino, ...) plutot difficiles.
[^] # Re: svn vs cvs
Posté par Philippe F (site web personnel) . En réponse à la dépêche KDE 3.4 officiellement sorti. Évalué à 6.
Les astucieux auront tout de suite note que cela signifie que tous les fichiers sont en double en local: version modifiee et version non modifiee. Ca prend donc deux fois plus de place, mais les fichirers texte ne prennent pas beaucoup de place.
A cote de ca, c'est _super_ pratique de pouvoir annuler ses changements rapidement, ou bien de regarder ce qu'on a change en une seconde.
[^] # Re: pourquoi virer autotools ?
Posté par Philippe F (site web personnel) . En réponse à la dépêche KDE 3.4 officiellement sorti. Évalué à 8.
Pour te repondre, je te redonne un bon dicton d'informaticien: "Il ne faut pas reinventer la roue. Sauf quand le premier inventeur a invente une roue carree".
autotools, c'est clairement une roue carree. C'est un arrachage de cheveux a maintenir. Parmis les milliers de contributeurs et parmi la quarantaine de developpeurs principaux de KDE (qui ont un sacre niveau en informatique), il y a en tout et pour tout deux developpeurs qui comprennent completement le systeme des autotools utilise par KDE et qui sont capables de le maintenir. Ca ne fait pas beaucoup.
Les developpeurs de KDE ne prennent pas des decisions techniques a la legere. Si ils se debarrassent d'autotools, c'est que ce n'etait plus gerable.
Il y a des super projets pour remplacer autotools, qui ont tous la caracteristiques d'etre simple a utiliser et simple a faire evoluer. Deux qualite qui manquent terriblement a autotools. Je peux te dire que le type qui s'occupe d'autotools pour KDE (il me semble que c'est Stephan Kulow) est super motive pour utiliser autre chose, pour te donner une idee du truc.
Scons semble etre une alternative interessante. Il y en a d'autres. Pourquoi se prendre la tete avec un systeme super complexe quand des alternatives plus simples existent.
Faut pas etre trop sentimental. Autotools etait une bonne solution au moment ou il a ete cree, mais aujourd'hui, l'outil ne fait plus le poids. Avoir python ou perl installe sur sa machine n'est pas une contrainte extraordinaire alors qu'a l'epoque ou autotools a ete cree, sh etait la seule dependance acceptable.
Par exemple, je suis toujours choque que ./configure ne detecte pas les erreurs de syntaxes dans ses options:
./configure --enable-truc-muche ne te renverra aucune erreur. Sauf que en fait, il fallait taper:
./configure --enable-trucmuche
Et encore, ca c'est un probleme mineur d'utilisateur, rien a voir avec la complexite de la mise en place du truc.
[^] # Re: Kmail
Posté par Philippe F (site web personnel) . En réponse au journal J'ai rêvé d'un client mail différent. Évalué à 3.
Sinon, je suis d'accord avec toi sur le fonctionnement global. Je suis passe de kmail a thunderbird et c'est l'horreur. Non content de gerer des comptes separes, il gere aussi les filtres separement. Je cherche encore le jour un un message envoye a la mailing list trucmuche doit etre filtre differamment suivant qu'il est arrive sur le compte X ou le compte Y. Sans compter que ca cree des bugs subtils sur thunderbird. Tu ne peux pas filtrer ton inbox global, quand tu affiches les filtres, il n'y a en fait que la moitie des filtres qui sont affiches, etc etc.
Je ne comprends pas du tout la raison de cette conception ou le compte individuel de mail prevaut sur la simplicite.
[^] # Re: hmmm
Posté par Philippe F (site web personnel) . En réponse au journal Exercices de compilations. Évalué à 2.
# Idee
Posté par Philippe F (site web personnel) . En réponse au journal Exercices de compilations. Évalué à 2.
Sinon, quitte a ecrire un langage, fait leur ecrire un langage qui leur apprend aussi des notions de qualite logicielle. Genre un langage prouvable, ou bien un langage a la eiffel, avec pre et post-assertion, ou bien un langage comme Ada, ou tous les intervalles de donnes sont parfaitement controlle.
L'idee etant de trouver un langage avec des caracteristiques plus robuste que la moyenne de ceux qu'ils manipulent (C etant le pire).
[^] # Re: XHTML strict ?
Posté par Philippe F (site web personnel) . En réponse à la dépêche Coding Party AlternC. Évalué à 2.
Maintenant, j'aimerai voir une alternative qui est aussi simple a gerer.
J'ai un besoin extraordinairement normal: je veux un index a gauche qui donne acces a toutes les pages de mon site web sur la droite. La solution frame est la seule solution simple qui permette de faire ca sans dupliquer l'index sur chacune des pages. Si j'ai un index de 20 pages et que je rajoute un lien, je ne veux pas mettre a jour 20 pages de contenu.
J'avais souleve le probleme avec Tristan Nitot il me semble, et il n'avait pas de solution a me proposer.
Si tu ne veux pas passer par des cadres, il te reste soit du scripting cote serveur (super lourd), soit faire des template que tu dois pre-processer avant de les transformer en html.
Bref, si t'es pas geek, la maintenabilite d'un site avec index est une gagure, a moins d'utiliser des trames.
Si je ne me suis pas exprime clairement, tu peux aller voir mon site http://phil.freehackers.org(...) (site tout pourri et pas valide, je sais) qui montre ce que je veux avoir. Index a gauche, titre en haut, contenu a droite.
[^] # Re: je n ai jamais fait de droit.
Posté par Philippe F (site web personnel) . En réponse au journal Ma licence. Évalué à 10.
Mozilla et Apache ont leur propre licence d'une part pour des questions d'ego (a mon avis) et aussi parce que leurs juristes se sont penches sur la GPL et ont dit qu'il y avait les problemes X et Y, qu'ils ont essaye de resoudre via leur nouvelle licence.
Meme avec les problemes de licence que des juristes peuvent imaginer sur la GPL, la LGPL ou la BSD, cela vaut mieux a mon avis qu'une licence maison, pour des raisons d'interoperabilites entre licence.
[^] # Re: Bonobo?
Posté par Philippe F (site web personnel) . En réponse à la dépêche GNOME 2.10 RC2. Évalué à 2.
Ouai, ca se peut. Ils doivent etre assis en face de ceux qui predisent depuis le debut de KDE que le projet va se planter:
- parce qu'il est base sur un toolkit proprietaire (KDE 1)
- parce qu'il n'utilise pas Corba (KDE 2)
- parce que Sun, Redhat, IBM, Ximian, etc investissent a fond dans Gnome et vont rendre KDE obsolete.
Finalement, il faut pas trop ecouter les racontars...
<< Pour ajouter un élément "technique", bonobo n'a rien à voir avec dlopen. >>
Oui et non. Il est possible de faire tourner les composants bonobo a l'interieur du meme processus, et dans ce cas, c'est bien un dlopen qui est utilise.
Ce que je disais, c'est que l'equivalent cote KDE de bonobo, c'est KPart + DCOP. KPart utilise dlopen ce qui le rend leger, facile a comprendre, facile a lancer (pas de fork comme en corba) et qui a permis aux composants KPart de se developper tres vite.
Le choix de corba dans bonobo rend la technologie plus complexe et limite par consequent son adoption.
[^] # Re: Hein ????
Posté par Philippe F (site web personnel) . En réponse à la dépêche GNOME 2.10 RC2. Évalué à 4.
Bon aller, en toute honnetete, j'ai vu un des derniers Gnome a linux solution et j'ai ete impressionne. J'ai trouve ca tres poli, tres clair. Apres, faut voir ce que ca donne a l'usage mais l'impression generale etait plutot positive.
C'est juste dommage que, non allez, je m'arrete la. Bonne chance pour le projet, il y a des gens vraiment brillant qui bossent dessus (qu'on retrouve sur xdg).
[^] # Re: Bonobo?
Posté par Philippe F (site web personnel) . En réponse à la dépêche GNOME 2.10 RC2. Évalué à -1.
Note que les problemes de bonobo ont ete evoque plutot par des supporters de Gnome.
[^] # Re: Bonobo?
Posté par Philippe F (site web personnel) . En réponse à la dépêche GNOME 2.10 RC2. Évalué à 5.
Je pense que le probleme de fond de bonobo, c'est que Corba est beaucoup trop complexe pour les besoins qu'en ont Gnome. Quand on a affaire a des gens qui travaillent pendant leur temps libre, mieux vaut eviter de leur compliquer la vie. A cote, KPart fournit les memes services que bonobo, mais ca a coute une semaine de dev et n'importe quel debutant motive peut comprendre comment ca marche en moins d'une semaine (man dlopen suffit en gros).
[^] # Re: Hein ????
Posté par Philippe F (site web personnel) . En réponse à la dépêche GNOME 2.10 RC2. Évalué à 1.
Ca, c'est la nouvelle philosophie de Gnome. Si tu regardes sur la ongueur de l'historique du projet, c'est un changement relativement recent.
Au contraire, a ses debuts, Gnome etait le bureau de hacker, avec le window manager le plus configurable de la planete et autres rejouissances.
[^] # Re: N'importe quoi...
Posté par Philippe F (site web personnel) . En réponse à la dépêche Theo de Raadt reçoit le FSF Award 2004. Évalué à -2.
[^] # Re: OSS pour se démarquer des grandes boites quand on est une petite boi
Posté par Philippe F (site web personnel) . En réponse au journal Enfin, je peux le dire: je recrute !!!. Évalué à 2.
Ca fait 6 ans que je suis dans le secteur, et 2 ans que j'etudie le marche de tres pres donc je sais comment me positionner.
Aujoud'hui, la pression sur ce marche se fait uniquement par les prix. Quand tu fabriques 10 millions ce cartes, chaque centime compte. Nous avons un positionnement bas-cout et c'est ce qui fait la force de notre solution. C'est tout. Et gemplus ne peut pas aller trop nous chercher du cote des prix car ils ont leur propres problemes, par exemple le fait qu'ils doivent remplire leurs usines.
<< Car entre 2 produits proprios, on choisira toujours le plus connu et celui avec la plus grosse boite derrière (qui peut en outre se permettre de régulièrement casser les prix pour tuer ses petits concurents).
>>
C'est vrai si les deux produits proprio sont strictement equivalents. Ce n'est pas le cas, grace a des choix techniques intelligents, on propose des prix qui sont 3 a 4 fois inferieur a ce que fait Gemplus ou Axalto (ex Schlumberger). Autant te dire que ca joue beaucoup. A cote de ca, le client se contrefout de savoir si notre produit est open source ou pas, du moment qu'on est certifie Visa ou certifie pour de la securite (EAL).
Le client gere la perennite avec au moins un double-sourcage sur l'OS (dans le marche qui m'occupe en ce moment, il y a un quadruple sourcage). L'open source dans notre cas n'assure pas du tout la perennite car il y a des couts de fabrication et de certification redhibitoire. Meme si les sources pouvaient etre entierement publique (ce n'est pas le cas, il y a des restrictions legales sur les composants), il faudrait couter environ 100 000 euro de cout de fabrication pour reprendre notre produit et en faire une carte. Ajoutes a cela des ingenieurs, des commerciaux plus la maitrise du produit, tu vois qu'il y a un cout considerable de reprise du produit. Il est beaucoup plus facile de demander a un concurrent un produit avec les memes caracteristiques. En plus, le client ne pourrait pas se lancer dans une telle operation, il doit rester strictement independant des fournisseurs d'OS.
Il faut bien comprendre que chaque type de marche a des regles de fonctionnement qui sont differentes, et qui font qu'un raisonnement qui est vrai pour un marche a la mysql ne s'applique pas forcement dans d'autres perspectives.
[^] # Re: roh
Posté par Philippe F (site web personnel) . En réponse au journal Enfin, je peux le dire: je recrute !!!. Évalué à 2.
Desole de te decevoir, mais je fais du libre pour des raisons morales (partage global de la connaissance) et pour le fun. Pour l'instant, le libre ne m'a rien rapporte economiquement et je n'ai pas l'impression que ca va changer.
C'est vrai qu'une carte a puce avec du code en ROM sera vachement plus perenne si le produit est en open source. Surtout quand il est legalement impossible de fournir la totalite du code source (parties liees aux composant qui sont sous NDA). Donc dans ce cas precis, le libre n'apporte aucune perennite.
Ca fait 10 ans que je fais du logiciel libre, j'ai bien reflechi a la question avant de lancer cette boite.
Comme je l'ai dit, on a meme fait un projet logiciel libre qui ne nous a rien rapporte, si ce n'est que nos sources sont sur le web et que les chinois peuvent maintenant faire un produit concurrent si ils "oublient" de respecter la licence.
<< le code est propre, on ne fait pas n'importe quoi >>
On propose des audits de code a nos clients et les certifications securitaires compreennent egaglement un audit de code. Cela dit, ca n'empeche pas de faire n'importe quoi, et cela vaut aussi pour les projets libres. Le fait que le code soit libre n'empeche pas les developpeurs de coder comme des cochons si c'est comme ca qu'ils travaillent.
[^] # Re: Soft-Révolution
Posté par Philippe F (site web personnel) . En réponse au journal Enfin, je peux le dire: je recrute !!!. Évalué à 7.
En fait, je ne cherche pas vraiment des developpeurs (meme si je ne cracherai pas dessus, soyons honnete) mais j'avais surtout envie de partager ca ici. Reussir a mener une boite jusqu'au point ou tu as besoin de recruter parce que le chiffre d'affaire commence a avoir une pente lineaire positive, voire exponentielle, c'est vraiment une etape tres importante pour moi.
Voila, le rapport avec Linux, c'est moi: j'utilise linux, je fais du logiciel libre, j'en mange, j'en dors mais je n'en vis pas.
[^] # Re: Le nerf de la guerre
Posté par Philippe F (site web personnel) . En réponse au journal Enfin, je peux le dire: je recrute !!!. Évalué à 5.
Ma boite ne peut pas me payer mais ca ne pose pas de probleme parce que je suis encore paye par les assedics (pour info, le gouvernement sponsorise la creation d'entreprise mieux que tous les business angel des etats-unis). En revanche, j'ai du travail et un peu de treso pour deux personnes de plus. Et ces deux personnes supplementaires devraient pouvoir generer suffisamment de revenu pour me payer mon salaire a moi (qui sera largement au dessus du smic, faut pas deconner quand meme).
Donc vous affoler pas, on paye les ingenieurs a un tarif raisonnable.
[^] # Re: roh
Posté par Philippe F (site web personnel) . En réponse au journal Enfin, je peux le dire: je recrute !!!. Évalué à 5.
C'est le meme probleme que pour les CPU libres. Il y a des couts enormes de fabrication, qui ne peuvent pas etre couvert par le modele open source. Une societe deja etablie peut se permettre de faire un invstissement la-dessus, en se disant qu'elle se rattrapera plus tard. Pas une societe en demarrage comme la notre.
[^] # Re: roh
Posté par Philippe F (site web personnel) . En réponse au journal Enfin, je peux le dire: je recrute !!!. Évalué à 4.
TheKompany a fait des logiciels open source non telechargeable. Non seulement, ils se sont mis a dos une partie de la communaute (quoi, c'est pas telechargeable) mais en plus, ils n'ont eu aucun contributeur. Et le produit n'est pas top. Bref, le bide complet.
[^] # Re: LL et commerce
Posté par Philippe F (site web personnel) . En réponse au journal Enfin, je peux le dire: je recrute !!!. Évalué à 5.
1. formation
2. maintenance
3. installation
4. developpements specifiques
Comment maximiser mes revenus ?
1. en faisant des logiciels tres difficiles a utiliser
2. en faisant des logiciels bugges necessitant beaucoup de maintenance
3. en faisant des logiciels difficile a installer, pour qu'on soit obliger de faire appel a moi pour une installation
4. en faisant des logiciels incomplets pour que me demande des evolutions.
CQFD.
Vous avez remarque, je viens de decrire le modele commercial de SAP. Certains disent que c'est aussi le modele de Motif.
Note que si tu fais un produit grand-public que tu vends, tu as interet au contraire a minimiser 1,2,3 et 4, de facon a genere le maximum de satisfaction et a faire decoller tes ventes.
Bon, donc heureusement que les logiciels libres sont developpes dans une optique qui n'est pas purement commerciale, que les developpeurs ont en general l'amour du travail bien fait, et surtout, que les choses sont deja suffisamment compliquee pour qu'on aie pas besoin d'en rajouter pour generer des revenus avec 1,2,3 et 4.
[^] # Re: roh
Posté par Philippe F (site web personnel) . En réponse au journal Enfin, je peux le dire: je recrute !!!. Évalué à 4.
Tout a fait. Donc si tu veux developper un produit qui te coute environ 4 annees hommes, tu peux faire le choix de passer 2 ans a 2 pour le developper et de le vendre ensuite (c'est ce que j'ai fait). Mais tu ne peux pas le donner.
Avec un modele mixte, il faut que j'assure mes revenus au minimum. Donc en admettant que je m'en sorte tres bien et que je bosse a mi-temps, il nous faudra 4 ans pour faire le meme produit. Pas de bol, dans 4 ans, ce produit n'aura bien rien d'innovant et aura perdu tout son interet commercial. A ce moment-la, je n'aurai plus qu'a fermer boutique.
En plus, des que ce n'est pas un projet ou il y a beaucoup d'utilisateurs, (comme apache), c'est tres dur d'attirer des developpeurs. On a developpe notre OS pendant un an en open source. On a eu _zero_ contributeurs. D'ailleurs, tu peux aller voir : http://jayacard.sf.net(...)
Donc finalement, j'ai beaucoup a perdre et tres peu a gagner en mettant ce projet en open source.
> Il y a de nombreux exemples, Qt de Trolltech, tous les outils d'installation et de config de mandrake, Dolibarr, NVU, et combien d'autres...
Il y a quelques exemples. Qt etant le plus impressionnant. Dolibarr, je ne connais pas. Les outils d'installe de mandrake sont open source parce que mandrake a d'autres sources de revenu qui financent leur developpement.
En dehors de Qt, il y a ACT qui fait un produit open source qui est aussi vendu, et qui leur sert reellement a assurer leurs revenus. A ma connaissance, ce sont les seuls societes qui vivent de la _vente_ d'un produit open source qu'elles ont developpe elles-meme.