Philippe F a écrit 2214 commentaires

Et pourquoi sh par dessus expect ? Pourquoi introduire une dépendance (et source de bug) supplémentaire ?

Python 2.4 a un très bon module subprocess pour lancer des programmes et gérer des pipes.

Tiens, un truc marrant que j'ai découvert en lua : il n' y a pas de distinction entre une liste et un dictionnaire (map pour les perleux).

La syntaxe est la même :
mydict[ mykey ] = myvalue

bien sur, mykey et myvalue peuvent être de type quelconques, un dictionnaire peut stocker un peu n'importe quoi et la clé doit juste être hashable.

Lua optimise le choix entre liste et dictionnaire en fonction de la taille de l'ensemble et de la présence de clusters de clés.

Je ne me souviens plus de l'algo, mais une implémentation naive pourrait être :
- moins de 10 élements, pas besoin de hash, on fait des listes chaînées et des comparaison de clé direct
- plus de 10 éléments, moins de 30 éléments mais cluster de clé sous forme d'entiers à valeur proche, on garde une liste chaînée
- tout le reste, on fait des hash avec des dictionnaires

Bien sur, l'implémentaiton est plus subtile que ça et optimisée pour des cas réels.

Au début, j'avais trouvé ça étrange mais en y réfléchissant, je trouve ça plutot sympa. Dans les faits, il y a très peu de différences entre une liste de 3 éléments et un dictionnaire de 3 éléments.

Si tu réfléchis au hash pour lisaac, il y a peut-être des choses à aller chercher là dedans.

Ils se gardent une source de revenu. Si tu veux mettre du Qt Extended dans ton téléphone, il faut négocier avec Qt Software. Cela dit, aujourd'hui, la plupart des matériels n'ont plus besoin de la version extended.

Sinon, CMake, ca marche très bien pour ce type de projet. Perso j'en suis très content.

J'ai pas vu de wiki gérant les documents openoffice, avec import, export et bien sur aucune perte de formattage ou données farfelues (tables excel incluses, images visio, ...) et affichage nickel.

Ou alors tu me proposes de laisser tomber tout ce qui fait d'un document bureautique un document bureautique et de repasser un un document texte.

En tant que directeur technique d'une PME, ça m'inspire quelques commentaires.

Je pense qu'en effet, une PME est mal adaptée à la poursuite d'une thèse CIFRE. Les PME sont souvent très tendues en budget, délais, main d'oeuvre et certaines urgences prennent le pas sur beaucoup de choses. Ca me parait incompatible avec le fait d'avoir une personne présente dans l'entreprise mais occupée à autre chose, travaillant sur un projet non stratégique pour l'entreprise.

Donc j'abonde dans ton sens, une plus grosse entreprise peut se permettre d'avoir un labo qui n'est pas forcément rentable à court ou moyen terme.

Par contre, pour ce qui est de trouver un boulot d'ingénieur, les PMEs peuvent être attractives. Ca dépend des goûts de chacun mais si l'ambiance est sympa, ca peut donner l'occasion de s'impliquer sur des gros projets, essayer des nouvelles idées, s'amuser un peu avec la technologie, ne pas s'emmerder avec la hiérarchie, utiliser du logiciel libre à tout va.

Tu veux dire le célèbre dessinateur de Lucky Luke ?

http://fr.wikipedia.org/wiki/Morris_(dessinateur)

Les vélos sont même dangereux pour les vélos, c'est pour dire !

Le nombre de fois où je croise des vélos sur la piste cyclable ... mais dans le mauvais sens. La plupart prennent la peine de s'écarter pour laisser passer les vélos dans le bon sens, mais pas tous.

Ou bien j'ai failli me prendre un vélo dans le cul parce que (en vélo moi-même), j'ai pilé pour laisser passer un piéton qui avait la priorité.

Moi je trouve ça bizarre que personne n'ai songé à ajouter Miguel De Icaza et Mathias Ettrich. Les deux bureaux Gnome et KDE sont quand même des contributions majeurs au logiciel libre. KDE est par exemple un des plus gros logiciels libres écrit en C++.

A côté, des trucs comme Drupal est Bittorrent me paraissent un peu insignifiant. Je suppose que ça doit dépendre des usages de chacun.

My name is Linus and I pronounce Linux as Linux

En ce qui me concerne, j'avais commencé par Emacs, trouvant les modes d'édition de Vim complètement imbitable. C'était en 1986. Après plusieurs semaines, j'en ai marre : le principal problème de emacs à cette époque, c'est que pour faire quoi que ce soit, il fallait modifier le fichier de configuration en lisp. Et pour l'aide, elle ne se trouvait bien sur qu'à l'intérieur d'emacs, et il fallait déjà savoir raisonnablement utiliser emacs rien que pour réussir à utiliser l'aide. Le fenêtrage était aussi bizarre, l'ouverture et la fermeture de fichier me semblait un peu louche.

Bref, je suis passé a jed, puis joe, puis jmacs, puis pico en trouvant que ça marchait très bien tout ces trucs.

Ce n'est que quelques années plus tard que j'ai tenté l'expérience vim, avec un bon tutorial, et que le gain obtenu par l'économie de déplacement des mes doigts m'a semblé significatif pour le conserver.

Donc je réfute le fait qu'on s'accroche au premier éditeur venu. J'ai rééssayé emacs à cette époque mais il m'a paru toujours aussi pénible à utiliser.

Etre ignorant et immature, oui, on l'a tous été.

Par contre, être arrogant, insultant et prétentieux, ça non, je ne l'ai jamais été.

J'ai toujours abordé l'informatique avec une grande fierté par rapport à mes acquis, mais aussi avec humilité, modestie et curiosité pour ce qui m'entoure. Ca m'a permis de progresser. Je ne pense pas que l'attitude "linux c'est de la merde et tous la moitié des informaticiens de la terre sont cons" de la personne dont on parle permette beaucoup de s'enrichir...

> Comme quoi, reprendre les bonnes idées en les améliorant, ça donne de super résultats.

Je tique un peu sur le "reprendre les bonnes idées de Gnome". Je pense pas que Gnome soit à l'origine de cette initiative (directement ou indirectement), c'est plutôt lié à la volonté de mieux gérer la communauté d'utilisateurs de KDE, qu'on a pu voir récemment avec la création du "Community Working Group" et du "Code of Conduct" ( http://dot.kde.org/1218525921/ ). Techbase n'est que le prolongement de cette action.

C'est quoi cette remarque à la con vis à vis des petites boites ? La carrière professionelle ne se résume pas à gravir les échelons d'une grosse boite.

Ca me fait penser à un copain chez Alcatel qui m'expliquait qu'il avait réussi à négocier de passer directement de l'échelon 308 à l'échelon 310 (en sautant le 309) et que donc dans 10 ans, il aurait des avantages plus tôt que les autres (restés encore à l'échelon 309, les pauvres). Sur certains projets, il devait rapporter tout ce qu'il faisait à 3 chefs différents. C'est vraiment caricatural mais c'est aussi la vie en grosse entreprise.

Les perspectives d'évolution personelles dans une petite boite sont intéressantes mais ne sont pas du même ordre :

- plutôt que de ne savoir faire qu'une seule chose, tu interviens sur toute la chaine de fabrication d'un produit : définition avec le client, conception, réalisation, test, livraison, support

- dans mon métier précis (les cartes à puce), on ne peut survivre que si on est plus rapide, meilleur et moins cher que les gros. Et on arrive, ça c'est stimulant. Avec les années, on a même accumulé plus d'expertise que les gros du secteur sur certains domaines.

- la connaissance est mieux partagée dans une petite boite (à condition de faire l'effort bien sur).

- si tu as une bonne idée sur une nouvelle façon de faire, tu peux tout mettre en place en un mois et il te faut juste l'approbation des 3 autres membres de l'équipe. Dans une grosse boite, mon expérience fut de deux ans pour mettre en place une bonne idée (genre un serveur svn avec notification par mail).

C'est ce qui me vient pour l'instant. Vraiment, j'ai pas envie de retourner dans une grosse boite ou pour faire ce que je fais aujourd'hui avec la marge de manoeuvre que j'ai, il faudrait que je lèche au moins 3 culs par jour.

Il y a un moyen de supprimer un journal ? Je cherche, je ne vois rien.

Si un modérateur passe par là, je veux bien qu'il le fasse.

J'avais jamais vu le contenu du forum mais c'est très très clairement beaucoup plus approprié comme endroit pour une telle annonce (j'aurai au moins appris quelque chose aujourd'hui).

Ah, j'avais jamais exploré cette partie du site.

Bon, je vais poster là-bas, c'est mieux.

Un des gros atouts de ORTS qui m'a attiré est de gérer tout le processus par mail. Comment se place votre logiciel par rapport à cela ?

(Sinon, super que vous soyez présents pour répondre à nos questions, ,c'est vraiment agréable).

Je comprends pas. Je ne vois pas de pub sur cet article.

Ou bien alors, annoncer la version majeure d'un logiciel libre est de la « publicité » que tu ne souhaites plus voir sur linuxfr ? Je trouve ca bizarre comme concept de dire que linuxfr ne devrait plus parler de logiciel libre parce que « c'est de la pub » . Sûrement, j'ai du mal comprendre ce que tu dis.

Par contre, un apiculteur amateur (comme mon père) sera ravi de vous en débarrasser. Les pompiers l'appellent régulièrement et comme l'article le dit, le décès des abeilles étant très courant, il a besoin de remplir ses ruches avec de la chaire fraîche.

Dans le fond, c'est super inquiétant. Qui peut remplacer le travail de pollinisation effectué par les abeilles ?

Si les chercheurs créent une start-up qui réussit bien, rapport beaucoup d'argent, emploie beaucoup de monde, il y a un retour positif vers l'économie française de plein de façons :
- balance des exportations
- taxes diverses
- baisse du chômage
- augmentation du rayonnement scientifique de la France

C'est sûr qu'en tant que créateur de startup, j'ai un point de vue biaisée sur le sujet, mais c'est un peu facile de dire que développer du logiciel libre est forcément mieux que créer une start-up.

Par exemple, si ils ont vendu leur start-up 28 millions d'euro, il y en a a priori 29% qui reviendront dans la poche de l'état français. C'est quand même pas rien. Ces 9 millions d'euro pourront être réinvestis pour une petite part dans du logiciel libre...

Plus subtil, tu remplaces toutes les adresses emails par la sienne. Comme ca, à la seconde où il va spammer, il se créée un Denial of Service.

Ca c'est du grand art.

Pour faire discret, tu remplaces une adresse sur 10 par la sienne. Et les autres tu les rends inexploitables.

Ca fait quand même pas très classe de le part de la FSF. Debian est une des distribution qui a placé le plus le libre au centre de sa démarche, en étant parfois même plus intaigriste exigeant que la FSF sur ses licenses.

Et la FSF choisit Ubuntu, la distrib qui rajoute des trucs proprio par dessus debian, et qui a la mauvaise réputation de ne pas reverser ses contributions à debian !

Je serai un mec de debian, j'aurai mal au cul.

Tu as raison sauf sur un point : il y a beaucoup de développeurs qui travaillent à l'heure actuelle sur plasma, alors que sur kicker, il n'y avait plus personne depuis plusieurs années.

Maintenant des développeurs qui travaillent sur la partie kicker de plasma, je dirai qu'il y en a au moins un A. J. S

Tout à fait, le besoin d'un changement de licence possible a propulsé ce besoin au premier plan.

Aussi une réponse au fait que certains développeurs peuvent disparaitre (soit d'internet, soit tout court). Si ils ont assigné leur code auparavant à KDE eV, ca permet de gérer des problématiques juridiques plus facilement.

La FLA mets aussi des protections autour du changement de licence qui serait initié par KDE eV:
- la priorité est avant tout de contacter le développeur original, c'est que quand vraiment ça ne marche pas que KDE eV peut envisager d'utiliser son droit de modification de licence.
- a priori, c'est uniquement pour passer d'une licence Open Source a une licence d'esprit Open Source. C'est pas pour tout relicencier en propriétaire (de tout façon, les membres de KDE eV s'y opposeraient).

Je confirme.

En partant du principe que "Scons est en python donc plus souple"; on se demande pourquoi utiliser Scons et pas plutôt juste python, ce serait "encore plus souple".

Ce que je veux dire, c'est que pouvoir tout faire avec un système de compilation, c'est pas le but. Le but, c'est de pouvoir compiler ce qu'on veut, correctement, et si possible rapidement, sans galérer dans l'écriture des règles de compilation.

Bien que fan de python, je dois reconnaitre que à l'usage, CMake est vraiment excellent. J'aurai préféré un autre système que des macros, et la gestion des chaines de caractères peut être un peu chiante, mais globalement, CMake fait son boulot très bien, pour tout un tas de plate-forme et de compilateur, avec des fichiers de configuration très simple à comprendre.

Et dieu sait que c'est pas du tout facile. C'est facile de faire compiler un projet sur une plate-forme donnée avec un compilateur donné. Maintenant, gérer x systèmes de gestion de lib dynamiques, sur y plate-formes différentes avec z compilateurs, c'est vraiment un truc chiant.

CMake s'en sort très bien, en gardant pour lui la complexité du truc et en exposant un langage de description des règles de compilation très simple. On peut même tirer partie des fonctionnalités spécifique de chaque plate-forme ou compilateur sans pour autant compromettre la généricité du CMakeLists.txt (l'équivalent du Makefile).