GuieA_7 a écrit 689 commentaires

J'ai personnellement écrit les 20000 premières lignes de MLdonkey en OCaml

Ok, enchanté et bravo !

Avant de faire de telles remarques, il faut se renseigner ! Des applications libres en OCaml, il y en a aussi (dont une partie des fameuses applis industrielles !)

Les torts sont partagés on va dire : je ne savais pas que Xen-Api était libre (je ne le connais même pas à vrai dire), mais en l’occurrence ça m'a l'air d'être un peu l'exception parmi tes super applis industrielles que tu citais en premier. Et c'est bien d'elles dont je parlais ("si dans le lot il y a avait des […]" ) ; parce que sinon, oui je sais qu'il y a des applications libres en Ocaml. Mais justement ce n'est pas forcément celles que tu cites pour convaincre qu'Ocaml c'est bien. Et pour cause, ce sont de 'petites' applications (cela n'a rien de péjoratif hein).

Donc je persiste, ça serait bien si il y avait plus de grosses briques à la fois libres et réussites industrielles en Ocaml. Par exemple en Java[*], même si ça va servir malheureusement à faire principalement des applications métiers proprios (mais ce n'est pas la question), il existe tout un tas de grosses briques libres qui font référence et rare sont les applications java qui n'en utilisent aucune.

[*] et je ne fais pas la promotion de Java, moi je suis principalement Pythoniste.

Je ne suis pas sûr de comprendre ce que tu veux dire dans cette phrase.

Alors je développe. Si un logiciel remplit mon besoin à 95%, je vais sûrement le modifier pour obtenir les 5% restants (et ce même s'il est écrit dans un langage vraiment tout pourri) plutôt que le réécrire depuis zéro an Ocaml, malgré toute la puissance de ce langage (d'où les 95% de lignes "qu'on n'a pas écrites").

Donc j'espère qu'Ocsigen sera une de ces briques libres de référence. Mais j'attends que des webapps reconnues l'utilisent ; les meilleurs frameworks ne sont devenus ce qu'ils sont que parce qu'ils étaient réellement utilisés par des tas d'applis qui les ont éprouvés. Voilà pourquoi je cherchais une section sur le site d'Ocsigen listant les utilisations de ce dernier.

En lisant ce forum, je m'aperçois que beaucoup ne savent pas encore qu'OCaml est sorti depuis longtemps du périmêtre clos des laboratoires, pour être utilisé dans de belles applications industrielles.

Ceci dit si dans le lot il y a avait des applications libres ça serait bien aussi ; maintenant on sait que Ocaml est sorti des labo et sert à faire des applications bien proprio aussi ! :)

Parce que les meilleurs lignes de code c'est aussi bien souvent celles qu'on écrit pas, aussi faciles soient elle à écrire.

Ocsigen semble donc aller dans la bonne direction, et sera encore plus convaincant quand de belles webapp libres et incontournables l'utiliseront (je n'ai n'ai rien vu de tel sur le site d'Ocsigen, fort joli au demeurant).

…la situation de tes commits à titre personnel. Il faudrait l'avis d'un juriste, mais à mon avis les commits que tu as fait sur ton temps personnel sont sous le copyright de ton employeur (tu es auteur, mais tu n'as pas le copyright).

• C'est sûrement dit dans ton contrat de travail : ça touche le domaine de ton entreprise (difficile de plus être le cas vu que c'est un projet de ton entreprise).
• Il est difficile de toute les façons de prouver que tu l'as fait sur ton temps libre (ton employeur peut dire que tu as codé au bureau, et ramené le patch chez toi).

Je pense que ton employeur ne te vole rien, tu lui a juste gracieusement offert ton temps (je sais ça ne te fait pas plaisir, mais je veux juste que tu ne te mettes pas dans la merde). Mais bon le mieux est de voir ça avec ton employeur ; du coup tu auras la réponse pour tes commits futurs.

Mais dans tous les cas (que tu aies le copyright ou non), en fait ça ne va pas changer grand chose pour le futur à mon avis. De toute les façons si 99% des commits viennent de ta boite, et bien elle contrôlera le développement. Il te reste le fork :

• Si ton employeur exige de récupérer ton copyright même pour ton temps libre, et bien du coup ça sera pareil pour le fork (ça restera du libre et tu contrôlerait ce projet ceci dit, mais pas sûr que ça te plaise).
• Cette fois ci parle en avant à ton employeur ; tu ne sembles pas vouloir te fâcher avec ta boite, mais ce n'est pas dit que cette idée leur plaise (ça fait un concurrent etc…).
• Avant le projet n'avançait plus du côté de ta boite, du coup tes commits allaient dans la seule version existante. Si tu forkes, la journée tes commits iront sur une version, et tes commits sur ton temps libre iront sur une autre version. Les 2 versions vont elles beaucoup diverger ? Essaieras tu de récupérer les avancées venant de ta boite dans ton fork ? Avec le temps ça risque d'être frustrant cette gymnastique et cette perte de temps.

Je dirais qu'au final il te restera les issues suivantes :

• Tant pis, tu as fait du zèle pour ta boite, et tu essais éventuellement d'en retirer quelque chose (une prime pour le site par exemple).
• Tu estimes être en position de force (car un technicien reconnu et difficilement remplaçable) : tu négocies pour obtenir plus de contrôle sur le projet (contributions externes, indépendance par rapport à ta boite etc…).
• Tu montes ta propre boite et tu fais vivre ton fork ; en tant que créateur d'entreprise, je ne peux que te prévenir que ça sera beaucoup moins pépère que ta vie de salarié ! Même si j'aimerais que plus de libristes franchissent le pas, il faut bien avouer que ce n'est pas fait pour tout le monde.

En espérant t'avoir aidé.

J'ai un Toshiba Satellite depuis plus de 3 ans, à la base acheté pour sa carte graphique Intel (pour n'avoir que des drivers libres), et finalement pour bosser sur de l'appli web et jouer à des petits jeux et bien il tient encore la route.

Tout ça pour dire que j'ai eu des problèmes au bout de 2 ans environ, à cause de la poussière dans le ventilateur/radiateur (mais ça le faisait s'éteindre, pas rebooter, donc peut être que je suis à coté de la plaque). Je suis allé jusqu'à l'ouvrir, et ce n'est pas forcément évident de le faire proprement. Au final j'ai constaté que la poussière est piégée sur le radiateur (une longue plaque de métal qui relie le ventilateur au processeur) et empêche la bonne évacuation de la chaleur. Un bon coup de bombe dépoussiérante a réglé le problème ; j'aurai pu le faire sans même ouvrir l'ordinateur, et je l'ai d'ailleurs fait depuis par prévention.

Voilà j'espère que ça pourra t'aider (au pire ça te coûtera le prix d'une bombe).

Le problème avec a=1 c'est que '1' est un int donc 'immutable'. Si tu passais une liste par exemple, tu pourrais la modifier à posteriori, même si je ne suis pas sûr que ce soit une bonne idée de structurer ton code comme ça.
Comme suggéré juste au dessus, tu devrais peut être envisager une approche plus objet. Je tape du python toute la journée et je n'utilise jamais 'global' ; je ne dis pas que c'est inutile, mais si on en vient à en utiliser beaucoup c'est qu'il y a sûrement un problème de design.

Le module functools de la lib standard permet, comme son nom l'indique, de faire de la programmation orientée fonctionnelle ; regarde du coté de partial, peut-être que ça t'ira :

from functools import partial

def foo(a, b):
    print a, b

bar = partial(foo, a=1)

bar(b=5) #> 1, 5

Limbo est une petite merveille qui a reçu de nombreuses récompenses (méritées). C'est un jeu de plateforme réflexion à la jouabilité 2D où un petit garçon erre dans le limbes ; il s'agit de résoudre des énigmes basées sur un moteur physique. Il est graphiquement superbe, tout en noir et blanc, et l'ambiance est très glauque (des enfants se font embrocher par des araignées géantes ou découper par des scies circulaires par exemple) ; il est assez court mais les quelques heures qu'il vous occupera seront du bonheur !

Sword & sworcery est lui aussi vraiment excellent. C'est un jeu d'aventure assez contemplatif dans un monde d'heroic fantasy. Graphiquement c'est du pixel art sublime, et les musiques sont fantastiques. C'est un OVNI vidéo-ludique, mais pourvu qu'on accroche c'est envoutant.

À noter qu'un Psychonauts 2 devrait sortir, puisque son créateur a réussi à faire financer son développement grâce à une campagne KickStarter.

J'espère juste que les portages Linux sont de qualité après les éloges que j'ai pu faire !

Le pire c'est que ton commentaire est drôle au second degré, et pertinent au premier.

On s'est mal compris : mon itérateur en python ne peut pas non plus en l'état être utilisé par 2 threads qui appelleraient ses méthodes de manière concurrente (il faudrait utiliser un mutex). En revanche chaque thread peut instancier un itérateur et l'utiliser dans son coin pour aller de 1 à 3. Ce n'est pas le cas de ta fonction avec la variable statique.

Le problème du static c'est que le code ne va pas être réentrant. Il vaudrait mieux faire un vrai itérateur. En l’occurrence en Python à la main ça aurait pu donner un truc comme ça (facile à convertir en C++) :

class Foo:
    def __init__(self):
        self._count = 1

    def __iter__(self): #pour pouvoir faire "for i in Foo():"
        return self

    def next(self):
        count = self._count

        if count > 3:
            raise StopIteration

        self._count += 1

        return count

On voit que le code avec les 'yield' est bien plus simple. On n'a pas par exemple à se soucier de mettre dans 'self' les valeurs qu'on veut garder dans le contexte, mais surtout la structure même du code est plus simple.

(Désolé si ma définition n'est pas très rigoureuse). C'est une routine pour laquelle l'environnement va sauvegarder le contexte d’exécution entre chacun de ses appels, ce qui fait que d'un appel à l'autre l’exécution de cette routine se fait de manière continue. Bon je vais éclaircir avec un exemple en Python.

Si j'écris une fonction de ce style :

def foo():
    return 1
    return 2
    return 3

Tu vois bien que ce code est stupide : il va retourner '1' à chaque appel, et les 2 autres 'return' sont inutiles. En revanche si j'écris :

def foo():
    yield 1
    yield 2
    yield 3

Grace à 'yield', Python va me générer tout seul une classe d'itérateur qui utilise mon code pour générer les valeurs successives. Je peux alors faire ça :

it = foo()
print it.next() # '1'
print it.next() # '2'

Ça aurait été faisable à la main évidemment, mais là c'est beaucoup plus court et simple. Ça permet rapidement de faire des choses complexes sans trop de se prendre la tête.

J'ai l'impression que les goroutines de Go justement permettent de faire des continuations (et c'est bien).

Pas de continuation nativement en C++, mais c'est sûrement faisable via des hacks bien pointus (ou avec des threads mais pas terrible pour les performances du coup). Et un goto c'est bien pour rester dans la frame d'une fonction, pas pour remonter dans la pile d'appel, si ton algo est récursif par exemple.
Il y a une petite dizaine d'années ma prof de Ocaml nous conseillait d'utiliser une exception pour remonter le résultat d'une recherche récursive de manière efficace. Ceci dit je ne suis pas un pro en Ocaml (je n'en ai pas fait depuis) et c'est peut être un mauvais conseil.

Désolé pour les erreurs et approximations, dues à ma flemme de chercher (l'important étant la position de Nintendo face au libre) et merci pour tes corrections.

Autant j'espère que ce que tu dis est vrai, autant je reste circonspect, car je pensais comme le post auquel tu réponds. En effet, si je me souviens bien, il y a quelques années il y a eu une affaire avec EA qui avait fait développer un jeu pour plateforme Nintendo par un studio. C'était un jeu d'aventure point n' click, et ledit studio avait utilisé ScummVM (sous GPL). Quand cela s'est su, la libération des sources a été demandé pour se conformer à la licence de ScummVM, mais d'un autre côté la licence du SDK de Nintendo interdisait justement le libre[]. EA s'est donc retrouvé pris en étau avec 2 licences contradictoires qu'il devait respecter, et avait finit par donner une somme d'argent aux développeurs de ScummVM, comme pour acheter une licence propriétaire, et n'avait pas libéré les sources.

[*] comme quoi on peut apprécier certains aspects d'une boite (je pense que Nintendo a certain des meilleurs game designers du monde, et j'admire leur ténacité face à des entreprises autrement plus grosses), et trouver au final que ce sont des gros b*t*rds !

Je n'ai pas été très clair, je vais reformuler. Firefox est un logiciel libre, destiné au grand public (RedHat ne l'est pas par exemple) et qui rapporte beaucoup d'argent à ses auteurs. Je ne voit pas d'autres soft dans ce cas (c'est à dire réunir les 3 critères - des cas qui réunissent 2 critères j'en voit beaucoup), mais je peux me tromper.

Je vais faire plusieurs remarques suite à tes différents posts :

• Premièrement tu compares l'argent récoltée par un logiciel libre (avec des dons visiblement) et les prix d'un freelance, ce qui n'a pas beaucoup de sens. Il faudrait comparer à l'argent gagné par un logiciel propriétaire gratuit 'équivalent' et qui accepterait les dons lui aussi. Au final ça ne serait sûrement pas bien différent à mon avis : le don n'est pas un business model valide pour du logiciel.
• Tu as l'air de penser qu'un freelance se fait 10 000€ par mois ; si certains s'en sortent certainement très bien, la réalité est bien différente. Il y a les taxes évidemment, mais surtout le freelance ne facture pas tous les jours du mois, vu qu'il va passer un certain temps à trouver des contrats. S'il ne facture rien dans le mois et bien il gagne 0€. Si être freelance c'était la recette facile pour une richesse assurée ça se saurait hein. Ceci dit tu es libre de faire freelance à mi-temps (et gagner 5000€ par mois selon toi) et faire du libre bénévolement le reste du temps…
• Il est clair de gagner sa vie comptant sur les dons (ou même en vendant) un logiciel libre pour le grand public ça ne marche pas malheureusement : Firefox est l'exception (et ce n'est pas une entreprise), Mandrake ne faisait pas que vendre son logiciel etc… Il faut vendre quelque chose qui apporte un plus. À une entreprise tu vends du support, de la formation, des jours de développement spécifique. Pour un particulier, il faut trouver autre chose ; par exemple sur pokecraft tu pourrais vendre les assets (et ne pas les mettre sous une licence libre), si ça te semble acceptable (parce que du coup le soft n'est pas vraiment libre). Tu serais assez vite fixé sur le nombre de gens réellement prêts à payer, et ce n'est pas du tout dit que tu gagne un smic.

En espérant avoir éclairé ta lanterne.

+ 1

À coté de ça, les jeux libres sortent régulièrement des releases mais le jeu ne passe rarement la phase de développement

Je me demande depuis longtemps si ça serait envisageable que la communauté des libristes rachète les sources (code et assets) de jeux propriétaires ; un peu comme pour Blender, mais en allant chercher les éditeurs (alors que NaN a fait sa proposition lors de sa faillite). Par 'envisageable' j'entends 'combien ils demanderaient' (vu que tout à un prix). Je pense principalement à:

• des jeux indépendants ayant reçu de bonnes critiques mais étant passé un peu à coté de leur public.
• des jeux un peu anciens et plus commercialisés.

Dans les 2 cas peut être pourrait-on obtenir la libération pour un prix attractif, les ayants droits recevant une somme inespérée.

Comme tu le dis, les jeux libres faits bénévolement passent rarement la phase de développement : c'est dur, il faut un moteur, suffisamment de ressources graphique et sonores, des niveaux bien conçus, pas mal de polish… En revanche pour un soft ayant déjà atteint un bon niveau (voire ayant déjà une communauté), le développement serait plus attractif. Je pense à Blender ou à Warzone 2100 qui sont de bons exemples ; ou même, dans un genre très différent, TrackMania, qui démontre que beaucoup de joueurs sont prêts à faire de la création pour un jeu qui les amuse.

Tu prends un exemple où les choses se passent plutôt bien à l'heure actuelle: un projet bien défini, 100% informatique où des tonnes de solutions toutes prêtes existent.

Non pas forcément. Quand tu te mets à utiliser un ERP, il faut beaucoup de customisation derrière quel que soit le degré de finition de l'ERP (et donc ça ne se passe toujours bien du tout).

si une entreprise s'arrange pour avoir dans son personnel (managers, ingénieurs) quelques personnes qui savent programmer, alors […]

Oui je suis d'accord, si elle arrive a avoir des gens qui savent en plus programmer, ça va être cool pour elle. Mais comment font les employeurs profanes en info pour savoir si un de leurs managers sait programmer ? Dans la vraie vie, le gars-qui-sait-programmer (selon le profane) c'est souvent un gars qui à réussi à faire une macro Excel. Pour l'avoir vu un bon nombre de fois, ça finit en souvent une appli interne infâme en Access ou en WinDev totalement non maintenable.

Je ne dis pas que sous traiter change cet état de fait, je dis juste que "il suffit de trouver quelqu'un qui sait programmer" ça sonne bien, mais il n'y pas de solution magique malheureusement.

Je ne suis pas sûr de te suivre. Tu veux dire que si une entreprise qui fait, par exemple, de l'ébénisterie, et fait toute sa gestion manuellement depuis des années, veut mettre en place une gestion informatisée (stocks, clients, commandes etc…), elle doit chercher un ébéniste qui sait programmer ?

Ah mais on est d'accord. Le pire c'est les boites qui arrivent à sous traiter leur coeur de métier où elles sont compétentes en interne, à des gens moins compétents (oui ça existe) !!

Je dis juste que quand on n'y connait rien, embaucher ou sous-traiter sera difficile ; si le mec qu'on embauche (que ce soit pour se constituer des compétences en interne, ou pour surveiller la sous traitance) est mauvais, et bien la suite s'annonce compliquée.

Pour la petite histoire, le SI de bras cassés a passé, au début, le plus clair de son temps à faire croire au patron que c'est nous qui étions la cause des problèmes de la bonne marche du projet (plutôt que de faire son boulot). Depuis, le patron a finit par comprendre qu'ils payaient toute une bande d'incapables depuis des années, et il cherche à dégraisser…

Mon commentaire disait justement qu'on a le même problème avec les employés ! Si tu es incapable de comprendre que tes employés sont incompétents, tu seras incapable de savoir que ton sous-traitant est incompétent.

D'où le fait que je dise que c'est compliqué.

perso je ne le traiterai pas d'incompétent

Je me suis peut être mal exprimé : je parlais précisément de mon 2ème exemple ; ces gens ont pondu une espèce d'ERP en PHP/MySQL. Donc oui, ils sont censés savoir faire une requête SQL (et les preuves de leur incompétence sont nombreuses, mais peu importe).

cest que les ssii essayent de tout faire et du coup ne font rien correctement

Je n'ai pas dit le contraire ; en fait j'ai même dit que je n'aimais pas les SSII…

les entreprises devraient commencer à embaucher quelques employés qui savent utiliser un ordinateur

Si je suis d'accord dans le fond (j'ai horreur des grosses SSII), ce n'est pas forcément aussi simple que ça. En effet, lorsque ladite entreprise n'a pas la culture informatique (ce n'est pas du tout son métier), et bien c'est difficile pour elle d'embaucher des gens compétents : ils sont rares, contrairement aux incompétents qui ont appris à cacher leur incompétence (surtout à ceux qui n'y connaissent rien). J'ai vu ce cas de figure à 2 échelles ; une fois un petit service informatique de 4 personnes dans une PME de quelques centaines d'employés, et une fois un service informatique de 150 personnes pour une entreprise de la grande distribution. Dans ce 2ème cas, les plus compétents du lot arrivent difficilement à pondre une requête SQL simpliste en 3 jours… Au moins le sous-traitant on peut s'en débarrasser un peu plus facilement.

et les geeks végètent en SSII

Mouais. Contrairement à un ouvrier peu qualifié qui n'a pas trop le choix, un informaticien compétent peut trouver un boulot sympa s'il s'en donne la peine. S'il se contente des mêmes SSII qui embauchent tous les bras cassés, et ben il ne peut s'en prendre qu'à lui même.

C'est un « ou » ou un « et » ?

Je parlais bien d'un « et ». On va dire qu'effectivement on ne peut pas toujours améliorer à la fois tous les critères que j'énumère, mais 2 ou 3 sans dégrader les autres est très souvent possible. Je travaille beaucoup avec des (talentueux) juniors, mais bien souvent ils se contentent de faire du code qui marche (ce qui est déjà bien) ; j'essaie de relire systématiquement leur code, et je les surprends souvent en améliorant tous (ou du moins la plupart) de ces critères. Et leur code est bien meilleur que ce que j'ai pu voir écrit par le mec lambda en SSII, ce qui doit représenter une grosse partie du code écrit dans le monde. Je n'ai évidemment pas la prétention d'en faire de même dans le kernel, mais l'informaticien de gestion de base n'est pas Linus Torvalds malheureusement…

Et moi je me suis toujours demandé comment on pouvait être aussi sûr qu'un code n'est "pas correct".

Autant il est difficile de dire qu'un code est correct, autant il est bien souvent facile de montrer qu'un code ne l'est pas. Si on peut le réécrire en 3 fois moins de lignes, en plus simple, plus robuste, plus lisible et plus performant, c'est que le vieux code n'était pas bien fameux.