wilk a écrit 1103 commentaires

même pas, c'est l'europe des brouzoufs, pas l'europe de la libre circulation des personnes :

http://www.vie-publique.fr/actualite/dossier/elargissement_union_eu(...)

« D'autres acquis communautaires ne s'appliqueront que de façon progressive
Ainsi les différentes déclinaisons du principe de la libre circulation des personnes au sein de l'Union (libre circulation des travailleurs, libre établissement et libre prestation des services) font l'objet de périodes transitoires. »

« En France, les restrictions ne seront applicables qu'aux seuls travailleurs salariés, toutes les autres catégories (étudiants, chercheurs, travailleurs indépendants, retraités) bénéficieront immédiatement du principe de libre circulation des personnes. Au bout de deux ans, la France pourra lever ces restrictions en fonction de la situation de son marché du travail, cette période transitoire ne pouvant dépasser cinq ans. »

Y a déjà un wiki pour gnuarch, et encore pas mal de choses à traduire en ligne... Je tenais à utiliser arch pour traduire arch !

Pour le tuto je préfère les balises rst, et ce qui est généré me semble pas mal (même si la feuille de style n'est pas encore complète) :
http://flibuste.net/libre/tlafr/(...) (4 pages maintenant)

On peut aussi générer du docbook, donc pas de soucis pour d'éventuels autres formats demandés.

ha oui ! j'ai fait un copié collé de mon domaine local...

Dit-toi que tout le monde n'a pas comme objectif de faire des scripts en php qui puissent tourner sur free.
Peut-être que les développeurs utilisent python, sqlite etc. pour autre chose que ce projet et qu'ils n'ont pas envie de changer de langage et d'outils toutes les 5 minutes.

Ce qui est lourd c'est que les hébergeurs qui acceptent de proposer des alternatives sont toujours aussi rares. Quand bien même on trouverait un hébergeur acceptant le python, ce serait une autre paire de manche que de lui fair accepter subversion... déjà cvs...

Par contre arch, darcs etc. sont de bonnes solutions dans le cas d'un hébergement pauvre puisqu'ils ne nécessitent pas de serveur.

C'est pas Sun qui est dans le caca mais ses employés : 3300 supressions de postes apparement (10% de l'effectif)... Sans compter ceux qui démissionnent !
S'ils ne meurent pas, ça va être comme pour apple, grace à des perfusions pour que les autres ne soient pas accusés de monopoles...

La garantie porte sur les moyens, pas sur les résultats. Toutes les licences stipulent que le programme est livré "tel quel".

Ce que j'ai vu des programmes codés en interne est généralement très loin de ce que l'on voit généralement dans les logiciels libres. Prend les tests unitaires par exemple... Dans les LL on voit parfois des dizaines ou centaines de tests unitaires, dans les boites de dev je n'en ai jamais vu un seul ! Bien sur ce sont des généralités, il y a des exceptions...

Il est strictement interdit d'utiliser un programme écris au boulot pour son usage personnel ou professionnel annexe. Sans parler des brevets...

Article L113-9

Sauf dispositions statutaires ou stipulations contraires, les droits patrimoniaux sur les logiciels et leur documentation créés par un ou plusieurs employés dans l'exercice de leurs fonctions ou d'après les instructions de leur employeur sont dévolus à l'employeur qui est seul habilité à les exercer.

Si, c'est profitable également et surtout pour l'auteur du logiciel !

Quand tu es salarié tu perd tous les droits d'utilisation du code que tu ponds, sauf si le logiciel est libre auquel cas tu conservera le droit de l'utiliser.

Pareil si tu es freelance ou une petite boite, en sous-traitance on demande souvent cette cession des droits d'utilisation.

Donc en faisant des logiciels libres ça permet de garder le droit d'utiliser son propre logiciel, ça paraît bête à dire comme ça mais c'est pourtant pas du tout évident !

Le fait de vendre un programme sous gpl est un bon argument de vente au niveau des clients : Liberté du client, pas de dépendance etc.

Il n'y a pas de garantie sur le fonctionnement, le fait que le client ait les sources fait qu'il ne peut pas dire qu'il ne sait pas ce qu'il achète, le côté pas de vis cachées.

Si les concurents utilisent le produit ça les obligera à un certaine reconaissance, ça fera une excellente pub. "mes concurents eux même utilisent mon produit, c'est pour dire s'il est bien !" Les concurents se placeront généralement plutôt sur la défensive, très perplexes plutôt que voleurs.

Et bien sûr, si l'application à un intérêt pour d'autres, il pourra y avoir un support de la comunauté...

Les développeurs vont travailler d'une autre manière. Ils vont pondre un meilleur code puisque "tout le monde va le voir" et ils pourront l'utiliser eux même pour d'autres projets pros ou pas.

La société peut très bien détenir le copyright.

Tu pourra y associer et étendre d'autres logiciels libres.

Liste non exhaustive :-)

Justement non, relis, j'ai bien précisé "le jour où j'ai voulu tester python", c'est ça qui m'a surpris moi même :-)

Mais puisque tu vas tester tu nous dira si ça te fait le même effet ! Ca dépend peut-être du baggage qu'on a derrière, je peux pas dire.

Plutôt que de longs arguments techniques, le mieux est d'essayer, tu prends toutes les combinaisons possibles et avec chacune d'entre elles tu code from scratch une fenêtre avec un tree-view d'un côté et deux trois zones de saisies de l'autre, puis te fait de tout ça un exécutable pour les plateformes que tu veux. Si tu dépasse la demi-heure tu passe à la combinaison d'à côté.

Pour te donner une idée, le jour où j'ai voulu tester python et wx j'ai tout simplement réalisé un visualiseur de photo dans la journée ! Un mois après je livrai un programme sous windows pour un client, depuis je n'ai plus eu besoin d'un autre langage. Pourtant j'avais quelques années de java et C derrière moi...

Ce qui me plait dans une interface web c'est justement le côté pauvre, c'est à dire sans script ni mise à jour dynamique, ce qui évite à mon avis énormément de situations inextricables au niveau de l'interface. C'est très rapide à développer et l'utilisateur obtient une interface extrèmement simple, utilisable n'importe où.

Hors le but de xul est d'étofer l'interface web au point de rejoindre le gui classique, avec tous ses avantages mais aussi ses défauts... Les quelques tests que j'ai fait m'ont fait planter le navigateur plusieurs fois par ex. Je trouve la réalisation d'interfaces sofistiqués extrèmement pénible à débuger.

Mais "C'est un peu l'effet que me fait XUL... " voulait être en forme interrogative, je ne connais pas bien et reste intéressé quand même :-)

Tu as raison, il y a une sorte de retour en arrière avec le côté "submit de page", mais c'est généralement de plus en plus aprécié par les utilisateurs du fait que l'interface est plus simple et moins buggé.
Pour les décideurs pressés, le mot "intranet" est plus efficace que le mot "gui".

J'ai également été agréablement supris de voir à quel point les utilisateurs comprennent et acceptent les restrictions duent à ce genre d'interface. Peut-être par habitude du navigateur ?

Bref, les avantages compensent largement les inconvénients, à tous les niveaux (développeur et utilisateur).

Je précise que je parle aussi bien d'applications industrielles que de gestion.

Un autre point important c'est qu'il suffit de dire à l'utilisateur, connecte toi sur http://monip:1234(...) pour tester son application à distance, royal et impressionant !

Par contre il faut éviter de tomber dans le piège de vouloir reproduire ce qu'on fait en GUI sur une interface WEB, par exemple utiliser du javascript etc... Là on perd tous les avantages et on arrive rarement au niveau de ce qu'on connait en GUI classique. C'est un peu l'effet que me fait XUL...

Où tu as vu que le dico français et des synonimes étaient libres ? T'as une url pour les télécharger ?

Question : vous faites des tests unitaires en PHP ? si oui, avec quoi ?

Oui, avec python ;-)

Non, sans blague, c'est vrai, il y a des librairies très pratiques pour tester n'importe quel serveur web. Je m'en sert même pour tester si des sites statiques passent le validateur.

http://wwwsearch.sourceforge.net/(...)

Il y a aussi http://webunit.sourceforge.net/(...) mais je n'ai jamais essayé.

A mon avis que je me partage, l'XP c'est un peu comme la prose, on en fait sans s'en rendre compte.

L'avantage de l'avoir mis sur papier c'est qu'on ne culpabilise plus lorsqu'on travaille avec le client et non pour le client, qu'on n'essaye pas de prévoir l'imprévisible, qu'on fait des tests unitaires au lieu de preuves théoriques, qu'on fait évoluer une application alors qu'elle n'est pas encore finie, qu'on fait des releases très fréquentes etc.

Il ne faut pas s'obliger à faire de l'XP, ou autre, il faut regarder ce qu'on fait et ensuite chercher si d'autres font pareil, et ainsi comment améliorer sa méthode.

Pour ce genre de chose, aucune hésitation : http://pygame.org(...) tu vas te régaler autant que ton bambin.

Si tu veux j'ai codé un sokoban avec, il n'est pas encore finis mais fonctionne bien, tu me le demande. Sinon j'ai aussi un morpion si tu veux voir comment ça marche : http://flibuste.net/libre/morpyon(...)

Pour couper court les poils du troll sur la lenteur des langages de scripts :
On se fout un peu qu'ils soient lent ou pas quand ils savent s'appuier au moment oportun sur des librairies natives. Il ne faudrait donc pas comparer la vitesse des langages mais plutôt la vitesse des librairies sur lesquelles il peut s'appuier.
L'erreur de java à été d'essayer de faire tout tout seul, d'où les lourdeurs qu'on connait alors que le langage en lui même est relativement rapide finalement.

Ceci n'empêche pas que python fasse bcp pour améliorer ses performances, du fait d'une menace d'attaque par tarte à la crème interposée ! Mais la condition reste que les améliorations ne doivent pas rendre la maintenance du langage problématique (ce qui est encore une différence avec java par ex)

Est-ce que tous les lcds sont dans le même cas ou il y a des différences à ce niveau suivant le modèle/marque ?

Tu vas te faire lyncher par les "scolaires", mais tu as tout à fait raison, l'apprentissage de l'assembleur permet d'avoir une bonne conaissance claire et limpide du fonctionnement d'un ordinateur au niveau programmation. Ce qui fait qu'après, l'apprentissage des langages de plus haut niveau coule de source.

En fait l'assembleur est à la programmation ce qu'est le libre aux licences propriétaires : on peut voir ce qui se passe réellement et ainsi apprendre et comprendre.

J'ai écris en chinois ou quoi ?

Les ssii peuvent justement vivre des produits gpl en développant du spécif et dans ce cas ça ne change strictement rien pour eux (vu qu'un spécif n'a aucun intérêt à être piraté etc...). La différence c'est que le client n'est pas piégé, il est donc content et paye éventuellement plus pour ça.

Et si l'argument de posséder les "sources" n'a aucun sens pour le client, l'argument comme quoi il pourra l'installer dans plusieurs agences, chez lui etc. est très important. Il suffit de lui faire lire la licence de n'importe quel soft propriétaire pour qu'il voye l'intérêt de la gpl ;-)

Y avait un ";-)" dans ma phrase... C'est justement la raison pour laquelle je ne me fie pas trop aux vendeurs du coin pour me conseiller !

J'ai même failli lui faire écrire ça sur un bon de commande pour rigoler...

Ta démonstration est fausse car tu parles de concurents, il ne vont donc pas s'arranger entre eux.

Si les concurents sont en fait des collègues et sont capables de s'arranger, du fait de la GPL la SSII n'a plus qu'à vendre à un seul d'entre eux et lui dire : "je vous fait le produit au prix fort, mais vous aurrez le droit de le redistribuer/revendre pour l'amortir" C'est donc au client de se démerder et comme il a vraiment besoin du produit il va trouver ses collègues.

Finalement la gpl est plus adapté aux développements pointus et sur-mesure car il sont destinés à être vendus en très petite quantité, voir qu'une seule fois, il n'y a donc pas le malaise de se dire qu'on aurait pu faire fortune en le vendant à d'autres par exemple. De plus les développements pointus répondent généralement à un réel besoin, il rentrent donc tout à fait dans la logique du libre qui est de répondre à un besoin et non d'essayer de créer un besoin pour vendre un produit...

Est-ce que quelqu'un connait codeville ?

http://bitconjurer.org/codeville/(...)


Why yet another version control system? All other version control systems require that you keep careful track of the relationships between branches so as not have to repeatedly merge the same conflicts. Codeville is much more anarchic. It allows you to update from or commit to any repository at any time with no unnecessary re-merges.

Codeville works by creating an identifier for each change which is done, and remembering the list of all changes which have been applied to each file and the last change which modified each line in each file. When there's a conflict, it checks to see if one of the two sides has already been applied to the other one, and if so makes the other side win automatically. When there's an actual not automatically mergeable version conflict, Codeville behaves in almost exactly the same way as CVS.


A l'inverse des autres il a l'air d'être d'une simplicité déconcertante. Je dit ça en me basant sur la page de présentation, j'ai jamais essayé.

Merci, ça à l'air très prométeur, bien qu'assez déroutant, j'imagine qu'il faut une bonne période d'adaptation.

Je démarre un projet en local, pour faire des commits très fréquents. Ensuite un développeur est intéressé, je dépose un repository sur un serveur sur lequel on commit tous les deux. Je part dans la montagne sans connexion internet, je me fait une copie du repository sur mon portable qui me permet de travailler tout en bénéficiant de la gestion de version, quand je rentre j'envoi la sauce sur le serveur.

Est-ce ce comme ça la vie avec Arch ? Parcequ'avec cvs c'est pénible à gérer ce genre de chose...