Philippe F a écrit 2204 commentaires

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).

Ca sert aussi à gérer la compilation : lancer make comme il faut pour qu'il passe le moins de temps possible, gérer les options de compilation, faire la génération de lien correctement, faire des lib statiques ou dynamiques.

Quand on survole, ça a l'air très simple mais quand on rentre dans les détails, c'est pas du tout du tout simple. Il y a des différences entre chaque compilateur, entre chaque plateforme. Il y a pleins de subtilités sur la façon de faire des libs dynamiques (installable, qui trouvent automatiquement leurs différences, ...).

Au départ KDE avait choisi scons mais la lenteur et l'absence de flexibilité et la quantité de travail à faire pour faire compiler KDE avec on fait qu'il a été rejeté.

A côté, CMake s'est imposé tranquillement mais surement. En tant que fan de python, ça me fait bizarre que ce soit un langage de compilation à base de Macros en majuscule qui marche mieux qu'un truc développé en python mais les faits sont là. Et les mecs de KDE font rarement des erreurs techniques.

D'après Thomas Nagy qui a bossé sur scons pour KDE, les problèmes de scons tenaient vraiment à son architecture. Il a d'ailleurs écrit waf à la suite de ça: http://code.google.com/p/waf/

KDE est vraiment très content avec CMake, il y a régulièrement des améliorations en terme de vitesse de compilation de rigueur, ou de correction de problèmes extrèmement subtils.

Pour ma part, je l'utilise en j'en suis très content. Aussi simple à utiliser que qmake, mais mieux supporté et plus souple.

La documentation pèche un peu parfois mais rien d'insurmontable. Je l'utilise principalement sous windows, avec mingw, pour faire des nightly builds de certains projets.

C'est prévu ? Pour moi, ca rendrait vraiment l'outil super intéressant.

Ca a toujours toujours été comme ça. KDE a toujours sorti des versions très régulièrement, tous les neuf mois avec au plus un mois de décalage. Les seuls versions qui ont vraiment dérapé, c'est KDE 2.0 et KDE 4.0, parce que elles demandaient une réécriture importantes des bibliothèques de bases et des applications.

Il y a toujours eu un processus très carré, feature freeze trois mois avant la sortie de la release, string freeze un mois avant, ouverture des branches de dev en parallèle.

La seule chose qui change pour la série KDE 4, c'est que les intervalles de release sont passés de 9 mois à 6 mois, ce qui les rends apparamment plus lisible pour le grand public.

Tu fais quand même un raccourci sévère. On aurait presque l'impression que Novell peut faire des choses sans ton accord. Le cheminement, c'est : tu travailles sur cette partie-là de Mono, tu fais le choix de donner ton copyright à Novell en sachant que tu perds le contrôle de l'utilisation de ton code, Novell peut faire ce qu'ils veulent de ton code.

La forme des ombres est d'ailleurs caractéristique d'une projection sur une surface plane, preuve une fois de plus s'il en était, que la terre est bien plate et non ronde comme nos dirigeant voudraient nous le faire avaler.

Ben il manque la touche windows et la touche menu windows.

Apple a bien essayé de ré-inventer le concept avec la touche pomme mais on sent que c'est du réchauffé et ça n'arrive pas à la hauteur d'un vrai clavier windows :

http://obligement.free.fr/images/clavier_windows.jpg

Tu devrais te pencher sur les basiccard :

http://www.basiccard.de/

Malgré le nom un peu effrayant, ce sont des cartes faciles à programmer. Il doit être possible d'en faire une carte PKCS#11. Après, elles doivent pouvoir être intégrées avec un simple lecteur PC/SC à coup de MUSCLE dans du Linux.

Tout ça, c'est de la théorie, mais pour une âme motivée, il n'y a pas d'obstacle majeur à la mise en pratique.

Tu as lu la nouvelle ?

Tu as raison d'avoir peur, toutes les distrib debian depuis 2006 utilisent une version d'OpenSSL qui n'utilise presque pas d'entropie.

Maintenant OpenSSL lui-même fonctionne correctement.

Ne jamais se fier à ses sens, toujours [...] garder à l'esprit que notre vision du monde est en permanence faussée par une grille de lecture qui nous est propre, faite de préjugés, de souvenirs, de ressentis, de peurs, fantasmes, etc.


Je suis un peu étonné par ton encouragement à rejeter nos sens. Pourquoi ne pas accepter au contraire, que nos expériences teintent nos ressentis. Qu'y a-t-il de mal à trouver qu'une pomme offerte par une jolie fille aura un goût différent que la même pomme, offerte par un clochard ?

Est-ce vraiment un objectif ultime de devenir une machine débarrassée de tout sentiment, de tout a priori, de tout souvenir, de tout biais, de toute expérience passée ? En ce qui me concerne, la machine objective n'est pas un idéal de vie. Et je suis heureux que mes décisions ne soient pas toutes rationnelles.

Je transformerai plutôt ton appel en :

Fiez vous à vos ressentis, vos intuitions ! Gardez à l'esprit et profitez du fait que notre vision du monde est colorée et enrichie par une grille de lecture qui nous est propre, faite de souvenirs, d'émotions, de ressentis.

Les tests sont intéressants, même si il faut les prendre avec des pincettes. Ca donne un aperçu du potentiel.

Un autre indice que le C n'est pas la panacée est arrivé par python. La version .NET de python (IronPython) est arrivé soit à égalité, soit a été légèrement plus rapide que la version en C de l'interpréteur python sur une série de benchmark officiels.

Ca veut bien dire que on peut faire plus vite que du C. Je pense que c'est vrai en particulier sur des projets complexes, où le compilateur peut prendre une décision plus informée que l'être humain.

Sinon pour lisaac, si je me souviens bien, lisaac analyse l'ensemble du programme pour en optimiser tous ses aspects. Ca veut dire que sur un petit programme, il peut enlever des contraintes que le programmeur en C garderait. Après, sur un très gros programme, on peut imaginer qu'il pourra enlever beaucoup moins de contraintes et donc aura plus de mal à générer du code performant. Ou peut-être au contraire, il découvrira des optimisations inaperçues à la vue du programmeur.

L'absence de notion de bibliothèque est aussi un problème. Si j'ai bien compris les dernières explications sur le sujet, la notion de bibliothèque va justement réduire les capacités d'optimisation de lissac, puisque celui-ci ne pourra pas optimiser la partie du code externe.

Si tout le monde migrait a lissac, ce serait un peu comme passer à une gentoo en stage 1. Un truc de geek quoi.