Personne ne se plaint d'avoir trop de choix, au contraire.
Ben si justement, quelqu'un se plaint, c'est la personne à laquelle tu réponds. C'est quand même gonflé de dire que cette personne n'existe pas.
Tu peux me rajouter aussi, je me plains d'avoir trop de choix. Nous sommes donc au moins deux, et à mon avis pas tous seuls. Détail qui a surement une importance, je n'utilise plus Linux sur mes ordi depuis longtemps, uniquement sur quelques serveurs par ça par là, tout comme mosfet. Je reste cependant passionné par le sujet et par le logiciel libre en général, que j'utilise à fond sur mon OS propriétaire (dont le nom commence par W).
Pourquoi est-ce génant d'avoir trop de choix ?
Interférence avec le but initial
Choix compliqués à trancher
Choix indécidables
Alors, je détaille:
1 Interférence avec le but initial
Je veux naviguer sur le web. Je me pose pas plus de questions que ça, juste naviguer. Lequel de 6 navigateurs suivants dois-je choisir, sachant que je ne suis pas un spécialiste des logiciels libres: Firefox, Epiphany, Konqueror, Chrome, Opera, Dillo ?
Et encore, j'en ai exclus des moins matures.
Mais moi, je veux pas choisir entre 64 trucs, je veux juste aller sur le web.
2 Choix compliqués à trancher
Mettons que finalement, je suis prêt à chercher à comprendre de quoi il retourne. Je vais passer du temps à me documenter sur Firefox, puis sur Opera, puis sur Chrome. Bon, côté javascript, ça se tient à peu près, côté support plugin aussi. Donc il faut creuser encore pour savoir lequel serait le meilleur navigateur. Finalement, aucun ne sort vraiment du lot, Opera est juste un peu moins populaire.
Idem si tu regardes les bureaux. Pour quelqu'un de pas trop regardant, Gnome, KDE, XFCE, c'est Schtroumpf Vert et Vert Schtroumph. La place du bouton OK/Cancel doit elle être un critère dans mon choix de décision de mon environnement du bureau ?
En fait, je suis obligé de me rajouter tout plein de critères qui n'ont pas tant d'importance pour moi et qui ne serve qu'à une chose: décider un truc difficile à décider. C'est donc une construction semi-artificielle.
Mais à quoi sert tout ce temps passé ?
3 Choix indécidables
Un certains nombre de choix des distributions Linux sont à mon sens indécidables, dans la mesure où ce qui différencie deux choix est hors de portée de l'utilisateur. LibreOffice ou OpenOffice ? Pour qq'un qui se fout de savoir si c'est GPL et si Oracle est méchant ou pas, le choix est indécidable. KDE ou Gnome rentre à mon avis dans la même catégorie.
Mais, après tout le travail d'analyse sur le choix que tu peux faire, l'utilisateur a l'impression au final de ne rien comprendre et de ne rien choisir. Finalement, cette notion de choix est plus marketing que réelle.
C'est un peu comme le sketch de Pierre Palmade:
Tu préfères avoir la grippe toute ta vie ou avoir 20 canards qui te suivent partout ?
Mais tu me dis « te plains pas, on te propose un choix ».
Oui, mais c'est pareil pour les voitures, les machines à laver, les téléphones portables, les abonnements téléphone portable.
Depuis 15 ans, ça doit bien faire la 15e fois que je vois ce type de projet: aider les projets à trouver des développeurs. Aucun n'a marché, bien qu'à chaque fois, tout le développement technique ait ét fait.
Pourquoi ça ne marche pas ? Parce que il n'y a aucun marché tout simplement. Pour avoir un marché, il faut des vendeurs et des acheteurs (des proposeurs et des réalisateurs dans ton cas).
Bien sur qu'il y a des vendeurs/proposeurs: 100% des logiciels libres pourraient utiliser un peu d'aide dans n'importe quel domaine: documentation, traduction, portage, correction de bug, nouvelle fonctionnalité, amélioration d'interface, plus de test, etc etc. C'est pas comme si un projet avait plus besoin d'aide qu'un autre.
Du côté des acheteurs/réalisateurs, qui trouve-t-on ? En grande majorité des développeurs pour travailler sur le code, quelque fois des utilisateurs avancés qui peuvent contribuer de l'aide, des traductions ou des suggestions intelligentes.
Cette population là n'a pas besoin de toi pour s'intéresser à un logiciel. Perso, je suis développeur. Si je veux contribuer à un logiciel, je vais choisir un logiciel que j'utilise, ou qui me plait par son concept. Je vais d'abord m’intéresser un peu à la communauté, m'inscrire à des mailing list, suivre un peu les versions qui sortent, le rythme, etc. Une fois que je suis familier, je vais contribuer quelque chose à ma portée.
Pour certains logiciels, petits, je peux avoir un élan spontané et corriger un bug ou me lancer dans un sujet précis (fonctionnalité, portage, …).
Dans tout ce processus, je n'ai eu aucun besoin d'intermédiaire, et ton système de petites annonces ne m'apporterait rien.
C'est pour ça que tous ces projets se plantent au bout de 6 mois ou 1 an.
A voir, car le parement de laine de verre brûle très bien aussi (c'est du papier kraft) et beaucoup plus vite que du chanvre. Ta maison partira encore plus vite en fumée…
Note que on a le même problème avec bash vs sh. Une très très grande partie des scripts shell qui sont écrits aujourd'hui se croient compatible sh alors que dans les faits, ils ne sont compatibles que bash. Les subilités sont extrèmement pointues, je ne m'en rappelle plus mais dans les faits, on a bloqué à coup de script le shell qu'on utilise (par exemple, dans l'init Sys5).
Le même problème existe aussi avec gcc. Nombre de logiciels libres écrits en C ou C++ ont en fait vérouillé leur plate-forme indirectement par l'utilisation de constructions supportées uniquement par gcc (au hasard, les macros avec nombre d'arguments variables).
Bref, plus ça va, plus on se recentre sur des logiciels dominants de l'écosystème. Est-ce un problème à ce point-là ? Je n'en suis pas sur.
On peut citer aussi dans le monde de la carte à puce la .NET card, carte à puce censée prendre le marché très réservé de la Javacard, elle même censée prendre le marché des cartes multiapplicatives qu'on peut mettre à jour à distance et sur le terrain. Elle faisait tourner un sous-ensemble des fonctionnalités .NET .
La seule vente de ce produit semble avoir été à Microsoft, pour ses employés.
C'était d'ailleurs le deuxième ratage de Ms dans le monde de la carte à puce, ils avaient aussi fait une tentative tout aussi ratée par le passé.
Pour un client qui utilise des systèmes mixtes Windows / Linux, leur nouveau FS est inutilisable. Ca veut dire que pour ces cas-là, on prendra du FAT32 si on est conservateur, du NTFS si on n' pas trop peur de se lancer.
Microsoft reconnait aujourd'hui l'existence de Linux sur le marché professionnel, et propose même un certain nombre de pont. Ils sont présents au salon Linux, etc etc. Donc ce positionnement est incohérent.
Python est un projet collaboratif international, mais je salue quand même le travail considérable qui a été fait par nos deux développeurs français sur cette version, à savoir Antoine Pitrou et Victor Stinner. Et en plus, ils lisent linuxfr !
Petite question sur le yield from: est-ce que c'est juste de la simplification de syntaxe, ou est-ce que on peut en attendre des légers gains de vitesse si on l'utilise par rapport à l'ancien idiome ?
C'est vrai que ce système de version est peu lisible pour les utilisateurs. Dans l'esprit de Gnome, je propose que chaque version ne soit identifiée que par un seul chiffre, le reste, c'est étant des broutilles de développeurs. Ah oui, il faut quand même sauter les chiffres impaires pour faire comme tonton Linus.
Travaillant dans le domaine de la carte à puce, je te confirme que c'est une question de production.
Pour te donner une idée ta carte a d'abord été une puce, fabriquée par un fondeur de puce, collée et soudée à un module (la partie qui fait la connexion électrique). Ca, c'est avant la partie plastique.
Ensuite, pour le plastique, tu as des machine qui tournent depuis à peu près 25 ans sur un format carte plastique standard carte de crédit, qui vont amener une carte plastique avec un trou, déposer de la colle puis le module, appuyer bien fort pour que ca colle, passer ca 10 minutes dans un four, puis ressortir la carte, faire des tests électrique dessus, la pousser dans une machine qui va la coller sur une feuille de papier, plier la feuille et la glisser dans une envelope, etc etc.
Imagine le nombre de machines différentes qui sont entrées en jeu (et je te parle pas de l'impression double-face, engravage pour les cartes bancaires, hologramme, etc), qui sont toutes calées sur le format carte de crédit (ou télécarte).
Changer le format de manipulation de la carte veut dire mettre à jour des équipement de plusieurs millions d'euros, avec des tests à réaliser derrière qui coûteraient pratiquement autant.
Qui plus est, le format microsim est peu pratique à manipuler par des machines ou des humains. Difficile de pincer la carte sans recouvrir le module, risque de faire tomber la carte, etc etc.
Lors de l'introduction de la production de carte sans-contact type pass Navigo, la principale problématique de l'industrie a été de savoir comment intégrer la sans-contact dans tout ce processus. Ca s'est à peu près bien passé. Par contre, si on parle de porte-clé sans-contact avec la même puce dedans, les coûts de productions explosent parce qu'on ne peut plus utiliser le processus existant de fabrication.
Sachant que le plastique, c'est vraiment la partie qui coûte pas cher sur ce produit, l'industrie est pas prêt de changer de format. Au mieux, elle finira par utiliser des plastiques moins polluant.
Ça suppose quand même d'avoir une grande base de code d'erreurs unifiés pour permettre la propagation assez simplement
Ca existe deja, suffit de reutiliser(Win32 en contient des centaines par exemple).
C'est vrai et c'est assez appréciable sous Win32. Mais c'est pas utilisable quand on fait un soft portable. Et c'est difficilement utilisable quand tu fais un soft qui assemble plusieurs bibliothèques ensemble. Voici donc deux cas, où la gestion d'erreur propre demande de développer son propre gestionnaire de codes d'erreur et de message.
Mon point de vue est que ces checks sont de toute facon tres rapide a ajoute
Oui pour un truc très simple, si l'application est structurée de cette façon. Non si tu veux faire un truc un minimum intelligent et détaillé, pour par exemple proposer une solution à quelques erreurs courantes.
L'exemple de la partition où tu peux pas écrire mais où tu veux sauver ton document est intéressant à traiter…
Une macro ne pourra jamais remplacer un traitement intelligent d'une erreur. Le fait est que le traitement intelligent et correct d'une erreur est quelque chose de complexe (donc difficile à faire bien), coûteux en temps de dev, mais en même temps, indispensable dès qu'on arrive sur des gros logiciels.
Joel On Software y consacre un article pas trop mal d'ailleurs, que j'ai la flemme de retrouver.
Exception exhaustif à la java (je déclare tout ce que je lève), laxiste à la python (chaque ligne de code peut me balancer 24 exceptions différentes) ou code de libération en C avec des goto, aucune méthode n'est parfaite mais ce qui est sur, c'est que ça demande de l'investissement.
Suivant la taille du logiciel et son utilité, cet investissement est à mon sens pas toujours justifié.
Pour élargir le débat:
On peut aussi prendre le cas d'erreur du disque plein, ou du logiciel qui s'execute sur une partition sans les droits d'écritures. C'est des cas réels, compliqués à gérer, dans lesquels il faut informer l'utilisateur pour qu'il resolve intélligemment son problème. Dans ces deux cas, un simple crash est une mauvaise porte de sortie car l'utilisateur doit être informé de la situation pour pouvoir la régler.
Sinon le nouveau langage Go introduit un truc intéressant: des routines qui sont exécutées à la sortie de la fonction, dans l'ordre inverse où elles sont été déclarées. La logique est bien de mettre toute la libération des ressources dans ces routines, de façon à ce qu'elles soit libérées automatiquement en cas d'erreur.
Mais là encore, d'une part il faut être très rigoureux et d'autre part, il y a des fois où la libération de ressource est compliquée et même avec toute la structure du langage, on ne peut pas se passer d'une bonne prise de tête pour traiter avec honneur tous les cas tordus.
Puisqu'on est dans de la vraie reflexion de fond, posons les bonnes questions.
Qui vérifie les valeurs de retour de printf ? Et que faire en cas d'échec de printf ?
En tout cas, le débat n'est pas inintéressant. Je rejoins PbPg sur le fait que faire un bon test et chaînage d'erreur est la base d'une bonne bibliothèque. Je le fais quand je développe des libs à usage externe. Et une des règles de base est d'ailleurs : ne jamais retourner true quand une fonction réussi. On retourne toujours 0 quand ça réussit de façon à pouvoir glisser dans le futur tous les cas d'erreurs nouveaux.
Ça suppose quand même d'avoir une grande base de code d'erreurs unifiés pour permettre la propagation assez simplement. Ça veut dire aussi qu'il faut convertir tous les cas d'erreurs des libs externes qu'on appelle. Ça peut vite être assez lourd. Mais très bien fait, ça permet d'identifier assez précisément une erreur quand une application se crash. C'est la différence entre "ah tiens mon application carte à puce crash" et "ah tiens, le driver propriétaire de mon lecteur de carte à puce n'arrive pas à faire de changement de vitesse de communication avec ma carte à puce", ce qui est tout de suite beaucoup plus utile.
Cela étant dit, je tends plutôt vers une approche à la Zenitram: au quotidien, très peu de soft que j'écris est critique, on est soit dans la ligne de commande, soit dans l'appli graphique à deux balles. Et donc la gestion de ce genre d'erreur me passe un peu au dessus. Côté diagnostic, j'ai plus tendance à m'appuyer sur du logging bien foutu que sur l'erreur elle-même retournée. Il est vrai que je fais beaucoup de python ou une bonne stacktrace est quand même sacrément claire!
C'est clair qu'on les attend au tournant du packaging, de la diversité matérielle et de la diversité des lib. A priori, si des gros et des très gros éditeurs n'ont en gros que 2-3 config linux à leur catalogue, avec un gros max 2 distributions, que peut faire un petit éditeur ? ZeroInstall ?
Je partage l'avis de Zenitram que ca restera avant tout Ubuntu, et peut-être une autre distrib si ils trouvent une part de marché significative de celle-ci sur les bureaux des utilisateurs…
Exit gentoo, debian, archlinux, Mandritruc, Mageia. Suse et Fedora ont un peu leur chance. Ca n'empêchera pas des passionnés de faire à peu près le travail de portage…
Pour l'instant Qt est un peu mal. Les ressources qu'il faut pour maintenir et développer Qt sont quand même assez colossales: il y a de la 3D, des portages sur un nombre incalculable de plate-formes, de l'embarqué, au moins deux paradigmes d'affichage, des widget en veux-tu en voilà, une bonne plate-forme de test et pas mal d'outils annexes.
Il me semble que c'est autour de 100 personnes chez Nokia qui bossaient sur Qt uniquement, avec des bureaux en Australie (bye bye), à Berlin et bien sur chez Nokia.
Même si Qt est en mode open-gouvernance, et ressemble à un gros projet logiciel libre, il reste de l'infrastructure qui sont inaccessible et surtout, une grosse masse de développeur à retrouver.
On peut imaginer que Qt devienne un nouveau WebKit: la brique commune d'un ensemble de société, qui le font tous évoluer de façon plus ou moins concertée. Mais même avec un modèle à la webkit, on trouve mal qui va payer 100 développeurs à plein temps.
Si Qt devient un simple logiciel libre et perd son armée de développeurs, le projet mourra ou stagnera sévèrement. Ce serait une grosse perte pour les trolls de linuxfr et pour le logiciel libre en général.
En ce qui me concerne, je m'attends à chaque fois à ce que Thunderbird s'améliore sur les points où il est plutôt mauvais et je suis à chaque fois déçu.
Citons par exemple :
L'éditeur de mail html qui est quand même pas mal à la ramasse. Dans le monde profesionnels, les mails en html sont la norme et pouvoir faire des reply où chacun commente le sujet du mail avec une couleur différente, c'est bien. Sauf que sous Thunderbird, ça prend 4 fois plus de temps à faire que sous Outlook, quand c'est tout simplement pas impossible.
Le format de stockage en mbox, qui commence à dater. J'ai des gros dossiers et Thunderbird me demande 5 ou 6 fois par jour si je veux "compacter" mes dossiers. Et si jamais il se lance dans la compaction, mon ordi rame pendant 10 minutes, les mails deviennent hyper peu réactif. Bof bof bof. Ce qui nous amène au sujet suivant.
Toujours pas de support maildir. Un support de "un mail = un fichier" est apparamment dipsonible, mais sans la comptabilité maildir. D'après l'auteur, ce serait faisable d'utiliser ça pour développer une extension maildir sauf que … ca ne gère pas les metadata des emails. Donc dans le cas d'un maildir partagé entre plusieurs clients mails, Thunderbird recopiera à chaque démarrage la totalité des contenu maildir pour régénérer les metadata. Top !
Le drag'n drop d'adresse depuis les messages mails, façon kmail (dans KDE 3.5 en tout cas), ce serait pas du luxe. Pour atrapper le nom et l'adresse d'un expéditeur pour la copier dans un autre message, il faut faire : transférer le message, copier le nom et l'adresse à la main, fermer le message. Top !
Les filtres sont un peu limités. On peut faire des conditions "et"+"et" ou bien "ou"+"ou" mais jamais "et"+"ou" ou encore "ou" + "sauf" (ce qui revient au précédent cas). C'est un peu chiant quand même. D'ailleurs, je dois avoir une centaine de filtre, on peut pas dire que Thunderbird facilite la gestion d'un grand nombre de filtres.
Je suis sur qu'en cherchant, je trouverai deux ou trois autres problèmes (par exemple le fait que c'est en permanence le plus gros consommateur de RAM et de CPU sur ma machine).
Heureusement qu'il a des qualités parce que sinon… Pour moi, ça reste le moins mauvais des clients mails portables open source (avec ces critères ça réduit pas mal les choix) mais on est loin d'un client mail satisfaisant.
Allez, je vais quand même dire un mot des trucs que j'aime bien:
- il est assez simple à l'usage (les filtres de Outlook sont mortels à configurer)
- l'intégration PGP marche vraiment bien (encore que les mails html + pgp, ça peut créer des soucis)
- le quick filter, c'est super pratique. Je vois mes collègues sous Outlook qui peinent pour retrouver des mails alors que moi, je les trouve facilement.
- le support imap tient bien la route apparamment (d'après mes collègues en tout cas).
En tout cas, maintenant, je n'attendrai plus rien de Thunderbird, et surtout pas l'imap !
Tout le monde n'est pas fan des DVCS. Perso, je suis au final assez réservé même si je reconnais les atouts. Le fonctionnement d'un DVCS par rapport à un CVCS reste nettement plus compliqué, et les gens ont plus de mal à le comprendre. Et la complexité mentale du modèle des branches est significative. Alors que pour un projet moyen qui n'a que des branches de maintenance, et une ou deux banches de dev par ci par là, SVN s'en sort très très très bien.
Je suis un grand fan de Python mais je suis tout à fait d'accord avec le fait que l'absence de typage ne facilite vraiment pas la documentation. Dans le style d'autre package où tu as besoin de lire le source, j'ai mechanize (Ok, c'est pas dans la lib officielle).
Les résultats me paraissent carrément, bon, surtout quand on voit le temps investi pour que la version Cython soit propre.
Ce qui est sympa avec PyPy, c'est qu'il y a encore pas mal de gains de performances attendus. Il vont encore rajouter des spécialisations pour cetains types dans le futur, et ils ont encore visisblement quelques idées de plus pour que ça tourne de plus en plus vite…
A lire les derniers blogs, je pense que PyPy devrait mouliner ton code pour l'optimiser à mort. Et le gros avantage par rapport à ton projet:
1. il est déjà écrit
2. il support l'ensemble complet de Python
Je viens de découvrir cet éditeur et j'en suis sur le cul (sauf que j'étais déjà assis … mais passons). Je cherchais un remplaçant potable à Notpad++ mais sans succès pour l'instant.
Et dire qu'il existe un éditeur :
- beau visuellement
- supportant un mode Vim (c'est hyper rare que ça marche bien et là, c'est un binding de qualité)
- extensible en python, mon langage préféré
- simple claire et rapide
Comment se fait-il que je n'en ai jamais entendu parlé ? Je vais tester pendant quelques semaines et je me fendrai peut-être de 60$ pour financer un logiciel—certe propriétaire—mais bien codé et de bonne qualité !
Ca fait longtemps que ça existe cet éditeur ? Et c'est one-man project j'imagine ?
[^] # Re: Bonne nouvelle
Posté par Philippe F (site web personnel) . En réponse à la dépêche Sortie d'Haiku Version 1 Alpha 4. Évalué à 6.
Ben si justement, quelqu'un se plaint, c'est la personne à laquelle tu réponds. C'est quand même gonflé de dire que cette personne n'existe pas.
Tu peux me rajouter aussi, je me plains d'avoir trop de choix. Nous sommes donc au moins deux, et à mon avis pas tous seuls. Détail qui a surement une importance, je n'utilise plus Linux sur mes ordi depuis longtemps, uniquement sur quelques serveurs par ça par là, tout comme mosfet. Je reste cependant passionné par le sujet et par le logiciel libre en général, que j'utilise à fond sur mon OS propriétaire (dont le nom commence par W).
Pourquoi est-ce génant d'avoir trop de choix ?
Alors, je détaille:
1 Interférence avec le but initial
Je veux naviguer sur le web. Je me pose pas plus de questions que ça, juste naviguer. Lequel de 6 navigateurs suivants dois-je choisir, sachant que je ne suis pas un spécialiste des logiciels libres: Firefox, Epiphany, Konqueror, Chrome, Opera, Dillo ?
Et encore, j'en ai exclus des moins matures.
Mais moi, je veux pas choisir entre 64 trucs, je veux juste aller sur le web.
2 Choix compliqués à trancher
Mettons que finalement, je suis prêt à chercher à comprendre de quoi il retourne. Je vais passer du temps à me documenter sur Firefox, puis sur Opera, puis sur Chrome. Bon, côté javascript, ça se tient à peu près, côté support plugin aussi. Donc il faut creuser encore pour savoir lequel serait le meilleur navigateur. Finalement, aucun ne sort vraiment du lot, Opera est juste un peu moins populaire.
Idem si tu regardes les bureaux. Pour quelqu'un de pas trop regardant, Gnome, KDE, XFCE, c'est Schtroumpf Vert et Vert Schtroumph. La place du bouton OK/Cancel doit elle être un critère dans mon choix de décision de mon environnement du bureau ?
En fait, je suis obligé de me rajouter tout plein de critères qui n'ont pas tant d'importance pour moi et qui ne serve qu'à une chose: décider un truc difficile à décider. C'est donc une construction semi-artificielle.
Mais à quoi sert tout ce temps passé ?
3 Choix indécidables
Un certains nombre de choix des distributions Linux sont à mon sens indécidables, dans la mesure où ce qui différencie deux choix est hors de portée de l'utilisateur. LibreOffice ou OpenOffice ? Pour qq'un qui se fout de savoir si c'est GPL et si Oracle est méchant ou pas, le choix est indécidable. KDE ou Gnome rentre à mon avis dans la même catégorie.
Mais, après tout le travail d'analyse sur le choix que tu peux faire, l'utilisateur a l'impression au final de ne rien comprendre et de ne rien choisir. Finalement, cette notion de choix est plus marketing que réelle.
C'est un peu comme le sketch de Pierre Palmade:
Mais tu me dis « te plains pas, on te propose un choix ».
Tout à fait, et ça me pose le même problème.
[^] # Re: L'esprit du libre disparait...
Posté par Philippe F (site web personnel) . En réponse au journal Deux ans de projet libre : bilan. Évalué à 7.
Depuis 15 ans, ça doit bien faire la 15e fois que je vois ce type de projet: aider les projets à trouver des développeurs. Aucun n'a marché, bien qu'à chaque fois, tout le développement technique ait ét fait.
Pourquoi ça ne marche pas ? Parce que il n'y a aucun marché tout simplement. Pour avoir un marché, il faut des vendeurs et des acheteurs (des proposeurs et des réalisateurs dans ton cas).
Bien sur qu'il y a des vendeurs/proposeurs: 100% des logiciels libres pourraient utiliser un peu d'aide dans n'importe quel domaine: documentation, traduction, portage, correction de bug, nouvelle fonctionnalité, amélioration d'interface, plus de test, etc etc. C'est pas comme si un projet avait plus besoin d'aide qu'un autre.
Du côté des acheteurs/réalisateurs, qui trouve-t-on ? En grande majorité des développeurs pour travailler sur le code, quelque fois des utilisateurs avancés qui peuvent contribuer de l'aide, des traductions ou des suggestions intelligentes.
Cette population là n'a pas besoin de toi pour s'intéresser à un logiciel. Perso, je suis développeur. Si je veux contribuer à un logiciel, je vais choisir un logiciel que j'utilise, ou qui me plait par son concept. Je vais d'abord m’intéresser un peu à la communauté, m'inscrire à des mailing list, suivre un peu les versions qui sortent, le rythme, etc. Une fois que je suis familier, je vais contribuer quelque chose à ma portée.
Pour certains logiciels, petits, je peux avoir un élan spontané et corriger un bug ou me lancer dans un sujet précis (fonctionnalité, portage, …).
Dans tout ce processus, je n'ai eu aucun besoin d'intermédiaire, et ton système de petites annonces ne m'apporterait rien.
C'est pour ça que tous ces projets se plantent au bout de 6 mois ou 1 an.
[^] # Re: débat dogmatique
Posté par Philippe F (site web personnel) . En réponse au journal Dépénalisation du cannabis. Qu'en pensez-vous ?. Évalué à 3.
A voir, car le parement de laine de verre brûle très bien aussi (c'est du papier kraft) et beaucoup plus vite que du chanvre. Ta maison partira encore plus vite en fumée…
[^] # Re: Et la compatibilité
Posté par Philippe F (site web personnel) . En réponse à la dépêche Archlinux utilise désormais systemd par défaut pour les nouvelles installations. Évalué à 7.
Note que on a le même problème avec bash vs sh. Une très très grande partie des scripts shell qui sont écrits aujourd'hui se croient compatible sh alors que dans les faits, ils ne sont compatibles que bash. Les subilités sont extrèmement pointues, je ne m'en rappelle plus mais dans les faits, on a bloqué à coup de script le shell qu'on utilise (par exemple, dans l'init Sys5).
Le même problème existe aussi avec gcc. Nombre de logiciels libres écrits en C ou C++ ont en fait vérouillé leur plate-forme indirectement par l'utilisation de constructions supportées uniquement par gcc (au hasard, les macros avec nombre d'arguments variables).
Bref, plus ça va, plus on se recentre sur des logiciels dominants de l'écosystème. Est-ce un problème à ce point-là ? Je n'en suis pas sur.
[^] # Re: La fin de Windows Phone
Posté par Philippe F (site web personnel) . En réponse à la dépêche Windows 8, Windows Server 2012 et Windows Phone 8. Évalué à 4.
On peut citer aussi dans le monde de la carte à puce la .NET card, carte à puce censée prendre le marché très réservé de la Javacard, elle même censée prendre le marché des cartes multiapplicatives qu'on peut mettre à jour à distance et sur le terrain. Elle faisait tourner un sous-ensemble des fonctionnalités .NET .
La seule vente de ce produit semble avoir été à Microsoft, pour ses employés.
C'était d'ailleurs le deuxième ratage de Ms dans le monde de la carte à puce, ils avaient aussi fait une tentative tout aussi ratée par le passé.
[^] # Re: système de fichier
Posté par Philippe F (site web personnel) . En réponse à la dépêche Windows 8, Windows Server 2012 et Windows Phone 8. Évalué à 7.
Pour un client qui utilise des systèmes mixtes Windows / Linux, leur nouveau FS est inutilisable. Ca veut dire que pour ces cas-là, on prendra du FAT32 si on est conservateur, du NTFS si on n' pas trop peur de se lancer.
Microsoft reconnait aujourd'hui l'existence de Linux sur le marché professionnel, et propose même un certain nombre de pont. Ils sont présents au salon Linux, etc etc. Donc ce positionnement est incohérent.
[^] # Re: système de fichier
Posté par Philippe F (site web personnel) . En réponse à la dépêche Windows 8, Windows Server 2012 et Windows Phone 8. Évalué à 7.
C'est vrai que Microsoft pourrait montrer sa bonne volonté en nous pondant un petit driver libre pour Linux, ça nous changerait du passé !
# Made in France
Posté par Philippe F (site web personnel) . En réponse à la dépêche Python 3.3 est sorti. Évalué à 3.
Python est un projet collaboratif international, mais je salue quand même le travail considérable qui a été fait par nos deux développeurs français sur cette version, à savoir Antoine Pitrou et Victor Stinner. Et en plus, ils lisent linuxfr !
Petite question sur le yield from: est-ce que c'est juste de la simplification de syntaxe, ou est-ce que on peut en attendre des légers gains de vitesse si on l'utilise par rapport à l'ancien idiome ?
# Popularité ?
Posté par Philippe F (site web personnel) . En réponse à la dépêche Sortie de Gambas 3.3. Évalué à 5.
Tu pourrais nous donner quelque chiffres sur la popularité de Gambas ? Et quelques exemples de programmes réels ?
Côté utilisateurs, tu as plutôt des développeur power-user, ou des débutants en programmation ?
[^] # Re: Typage statique ou dynamique?
Posté par Philippe F (site web personnel) . En réponse à la dépêche Sortie de Gambas 3.3. Évalué à 3.
Du coup, on pourrait surement écrire un interpréteur Gambas en PyPy ! Je serai curieux de voir les perfs par rapport à du llvm.
[^] # Re: ça me rapelle...
Posté par Philippe F (site web personnel) . En réponse au journal GNOME : le début de la fin ? le problème avec le projet GNOME. Évalué à 2.
Oui, mais le neveu Gnome fait toujours comme Tonton faisait il y a 20 ans…
[^] # Re: ça me rapelle...
Posté par Philippe F (site web personnel) . En réponse au journal GNOME : le début de la fin ? le problème avec le projet GNOME. Évalué à 3.
C'est vrai que ce système de version est peu lisible pour les utilisateurs. Dans l'esprit de Gnome, je propose que chaque version ne soit identifiée que par un seul chiffre, le reste, c'est étant des broutilles de développeurs. Ah oui, il faut quand même sauter les chiffres impaires pour faire comme tonton Linus.
Ok, je sors ------> []
[^] # Re: Taille standardisé
Posté par Philippe F (site web personnel) . En réponse au journal Nano SIM maxi pollution.. Évalué à 10.
Travaillant dans le domaine de la carte à puce, je te confirme que c'est une question de production.
Pour te donner une idée ta carte a d'abord été une puce, fabriquée par un fondeur de puce, collée et soudée à un module (la partie qui fait la connexion électrique). Ca, c'est avant la partie plastique.
Ensuite, pour le plastique, tu as des machine qui tournent depuis à peu près 25 ans sur un format carte plastique standard carte de crédit, qui vont amener une carte plastique avec un trou, déposer de la colle puis le module, appuyer bien fort pour que ca colle, passer ca 10 minutes dans un four, puis ressortir la carte, faire des tests électrique dessus, la pousser dans une machine qui va la coller sur une feuille de papier, plier la feuille et la glisser dans une envelope, etc etc.
Imagine le nombre de machines différentes qui sont entrées en jeu (et je te parle pas de l'impression double-face, engravage pour les cartes bancaires, hologramme, etc), qui sont toutes calées sur le format carte de crédit (ou télécarte).
Changer le format de manipulation de la carte veut dire mettre à jour des équipement de plusieurs millions d'euros, avec des tests à réaliser derrière qui coûteraient pratiquement autant.
Qui plus est, le format microsim est peu pratique à manipuler par des machines ou des humains. Difficile de pincer la carte sans recouvrir le module, risque de faire tomber la carte, etc etc.
Lors de l'introduction de la production de carte sans-contact type pass Navigo, la principale problématique de l'industrie a été de savoir comment intégrer la sans-contact dans tout ce processus. Ca s'est à peu près bien passé. Par contre, si on parle de porte-clé sans-contact avec la même puce dedans, les coûts de productions explosent parce qu'on ne peut plus utiliser le processus existant de fabrication.
Sachant que le plastique, c'est vraiment la partie qui coûte pas cher sur ce produit, l'industrie est pas prêt de changer de format. Au mieux, elle finira par utiliser des plastiques moins polluant.
[^] # Re: Et printf ?
Posté par Philippe F (site web personnel) . En réponse au journal Genèse d'un journal. Évalué à 2.
C'est vrai et c'est assez appréciable sous Win32. Mais c'est pas utilisable quand on fait un soft portable. Et c'est difficilement utilisable quand tu fais un soft qui assemble plusieurs bibliothèques ensemble. Voici donc deux cas, où la gestion d'erreur propre demande de développer son propre gestionnaire de codes d'erreur et de message.
Oui pour un truc très simple, si l'application est structurée de cette façon. Non si tu veux faire un truc un minimum intelligent et détaillé, pour par exemple proposer une solution à quelques erreurs courantes.
L'exemple de la partition où tu peux pas écrire mais où tu veux sauver ton document est intéressant à traiter…
[^] # Re: Je pense que tu confonds les cas où c'est nécessaire
Posté par Philippe F (site web personnel) . En réponse au journal Genèse d'un journal. Évalué à 4.
Une macro ne pourra jamais remplacer un traitement intelligent d'une erreur. Le fait est que le traitement intelligent et correct d'une erreur est quelque chose de complexe (donc difficile à faire bien), coûteux en temps de dev, mais en même temps, indispensable dès qu'on arrive sur des gros logiciels.
Joel On Software y consacre un article pas trop mal d'ailleurs, que j'ai la flemme de retrouver.
Exception exhaustif à la java (je déclare tout ce que je lève), laxiste à la python (chaque ligne de code peut me balancer 24 exceptions différentes) ou code de libération en C avec des goto, aucune méthode n'est parfaite mais ce qui est sur, c'est que ça demande de l'investissement.
Suivant la taille du logiciel et son utilité, cet investissement est à mon sens pas toujours justifié.
Pour élargir le débat:
On peut aussi prendre le cas d'erreur du disque plein, ou du logiciel qui s'execute sur une partition sans les droits d'écritures. C'est des cas réels, compliqués à gérer, dans lesquels il faut informer l'utilisateur pour qu'il resolve intélligemment son problème. Dans ces deux cas, un simple crash est une mauvaise porte de sortie car l'utilisateur doit être informé de la situation pour pouvoir la régler.
Sinon le nouveau langage Go introduit un truc intéressant: des routines qui sont exécutées à la sortie de la fonction, dans l'ordre inverse où elles sont été déclarées. La logique est bien de mettre toute la libération des ressources dans ces routines, de façon à ce qu'elles soit libérées automatiquement en cas d'erreur.
Mais là encore, d'une part il faut être très rigoureux et d'autre part, il y a des fois où la libération de ressource est compliquée et même avec toute la structure du langage, on ne peut pas se passer d'une bonne prise de tête pour traiter avec honneur tous les cas tordus.
# Et printf ?
Posté par Philippe F (site web personnel) . En réponse au journal Genèse d'un journal. Évalué à 6.
Puisqu'on est dans de la vraie reflexion de fond, posons les bonnes questions.
Qui vérifie les valeurs de retour de printf ? Et que faire en cas d'échec de printf ?
En tout cas, le débat n'est pas inintéressant. Je rejoins PbPg sur le fait que faire un bon test et chaînage d'erreur est la base d'une bonne bibliothèque. Je le fais quand je développe des libs à usage externe. Et une des règles de base est d'ailleurs : ne jamais retourner true quand une fonction réussi. On retourne toujours 0 quand ça réussit de façon à pouvoir glisser dans le futur tous les cas d'erreurs nouveaux.
Ça suppose quand même d'avoir une grande base de code d'erreurs unifiés pour permettre la propagation assez simplement. Ça veut dire aussi qu'il faut convertir tous les cas d'erreurs des libs externes qu'on appelle. Ça peut vite être assez lourd. Mais très bien fait, ça permet d'identifier assez précisément une erreur quand une application se crash. C'est la différence entre "ah tiens mon application carte à puce crash" et "ah tiens, le driver propriétaire de mon lecteur de carte à puce n'arrive pas à faire de changement de vitesse de communication avec ma carte à puce", ce qui est tout de suite beaucoup plus utile.
Cela étant dit, je tends plutôt vers une approche à la Zenitram: au quotidien, très peu de soft que j'écris est critique, on est soit dans la ligne de commande, soit dans l'appli graphique à deux balles. Et donc la gestion de ce genre d'erreur me passe un peu au dessus. Côté diagnostic, j'ai plus tendance à m'appuyer sur du logging bien foutu que sur l'erreur elle-même retournée. Il est vrai que je fais beaucoup de python ou une bonne stacktrace est quand même sacrément claire!
[^] # Re: Oh les approximations pour prêcher sa paroisse
Posté par Philippe F (site web personnel) . En réponse au journal Banc d’essai OpenGL/Direct3D de Source engine par Valve. Évalué à 1.
C'est clair qu'on les attend au tournant du packaging, de la diversité matérielle et de la diversité des lib. A priori, si des gros et des très gros éditeurs n'ont en gros que 2-3 config linux à leur catalogue, avec un gros max 2 distributions, que peut faire un petit éditeur ? ZeroInstall ?
Je partage l'avis de Zenitram que ca restera avant tout Ubuntu, et peut-être une autre distrib si ils trouvent une part de marché significative de celle-ci sur les bureaux des utilisateurs…
Exit gentoo, debian, archlinux, Mandritruc, Mageia. Suse et Fedora ont un peu leur chance. Ca n'empêchera pas des passionnés de faire à peu près le travail de portage…
[^] # Re: Petit rappel historique
Posté par Philippe F (site web personnel) . En réponse au journal Quel avenir pour Qt ?. Évalué à 10.
Est-ce que c'est pas justement ce qui a été fait avec QtMobility et QtQuick ?
[^] # Re: Petit rappel historique
Posté par Philippe F (site web personnel) . En réponse au journal Quel avenir pour Qt ?. Évalué à 9.
Pour l'instant Qt est un peu mal. Les ressources qu'il faut pour maintenir et développer Qt sont quand même assez colossales: il y a de la 3D, des portages sur un nombre incalculable de plate-formes, de l'embarqué, au moins deux paradigmes d'affichage, des widget en veux-tu en voilà, une bonne plate-forme de test et pas mal d'outils annexes.
Il me semble que c'est autour de 100 personnes chez Nokia qui bossaient sur Qt uniquement, avec des bureaux en Australie (bye bye), à Berlin et bien sur chez Nokia.
Même si Qt est en mode open-gouvernance, et ressemble à un gros projet logiciel libre, il reste de l'infrastructure qui sont inaccessible et surtout, une grosse masse de développeur à retrouver.
On peut imaginer que Qt devienne un nouveau WebKit: la brique commune d'un ensemble de société, qui le font tous évoluer de façon plus ou moins concertée. Mais même avec un modèle à la webkit, on trouve mal qui va payer 100 développeurs à plein temps.
Si Qt devient un simple logiciel libre et perd son armée de développeurs, le projet mourra ou stagnera sévèrement. Ce serait une grosse perte pour les trolls de linuxfr et pour le logiciel libre en général.
[^] # Re: c'est quoi le rapport ?
Posté par Philippe F (site web personnel) . En réponse à la dépêche Firefox et Thunderbird, livrée 14. Évalué à 6.
En ce qui me concerne, je m'attends à chaque fois à ce que Thunderbird s'améliore sur les points où il est plutôt mauvais et je suis à chaque fois déçu.
Citons par exemple :
L'éditeur de mail html qui est quand même pas mal à la ramasse. Dans le monde profesionnels, les mails en html sont la norme et pouvoir faire des reply où chacun commente le sujet du mail avec une couleur différente, c'est bien. Sauf que sous Thunderbird, ça prend 4 fois plus de temps à faire que sous Outlook, quand c'est tout simplement pas impossible.
Le format de stockage en mbox, qui commence à dater. J'ai des gros dossiers et Thunderbird me demande 5 ou 6 fois par jour si je veux "compacter" mes dossiers. Et si jamais il se lance dans la compaction, mon ordi rame pendant 10 minutes, les mails deviennent hyper peu réactif. Bof bof bof. Ce qui nous amène au sujet suivant.
Toujours pas de support maildir. Un support de "un mail = un fichier" est apparamment dipsonible, mais sans la comptabilité maildir. D'après l'auteur, ce serait faisable d'utiliser ça pour développer une extension maildir sauf que … ca ne gère pas les metadata des emails. Donc dans le cas d'un maildir partagé entre plusieurs clients mails, Thunderbird recopiera à chaque démarrage la totalité des contenu maildir pour régénérer les metadata. Top !
Le drag'n drop d'adresse depuis les messages mails, façon kmail (dans KDE 3.5 en tout cas), ce serait pas du luxe. Pour atrapper le nom et l'adresse d'un expéditeur pour la copier dans un autre message, il faut faire : transférer le message, copier le nom et l'adresse à la main, fermer le message. Top !
Les filtres sont un peu limités. On peut faire des conditions "et"+"et" ou bien "ou"+"ou" mais jamais "et"+"ou" ou encore "ou" + "sauf" (ce qui revient au précédent cas). C'est un peu chiant quand même. D'ailleurs, je dois avoir une centaine de filtre, on peut pas dire que Thunderbird facilite la gestion d'un grand nombre de filtres.
Je suis sur qu'en cherchant, je trouverai deux ou trois autres problèmes (par exemple le fait que c'est en permanence le plus gros consommateur de RAM et de CPU sur ma machine).
Heureusement qu'il a des qualités parce que sinon… Pour moi, ça reste le moins mauvais des clients mails portables open source (avec ces critères ça réduit pas mal les choix) mais on est loin d'un client mail satisfaisant.
Allez, je vais quand même dire un mot des trucs que j'aime bien:
- il est assez simple à l'usage (les filtres de Outlook sont mortels à configurer)
- l'intégration PGP marche vraiment bien (encore que les mails html + pgp, ça peut créer des soucis)
- le quick filter, c'est super pratique. Je vois mes collègues sous Outlook qui peinent pour retrouver des mails alors que moi, je les trouve facilement.
- le support imap tient bien la route apparamment (d'après mes collègues en tout cas).
En tout cas, maintenant, je n'attendrai plus rien de Thunderbird, et surtout pas l'imap !
[^] # Re: SVN vs Git
Posté par Philippe F (site web personnel) . En réponse au journal De tout, de rien, des bookmarks, du bla bla. Évalué à 3.
Et c'est justement ce qu'ils ne veulent pas…
Tout le monde n'est pas fan des DVCS. Perso, je suis au final assez réservé même si je reconnais les atouts. Le fonctionnement d'un DVCS par rapport à un CVCS reste nettement plus compliqué, et les gens ont plus de mal à le comprendre. Et la complexité mentale du modèle des branches est significative. Alors que pour un projet moyen qui n'a que des branches de maintenance, et une ou deux banches de dev par ci par là, SVN s'en sort très très très bien.
[^] # Re: Le titre est trop long
Posté par Philippe F (site web personnel) . En réponse au journal Typage statique versus typage dynamique. Évalué à 2.
Je suis un grand fan de Python mais je suis tout à fait d'accord avec le fait que l'absence de typage ne facilite vraiment pas la documentation. Dans le style d'autre package où tu as besoin de lire le source, j'ai mechanize (Ok, c'est pas dans la lib officielle).
[^] # Re: Pypy
Posté par Philippe F (site web personnel) . En réponse au journal pythran: python -> c++. Évalué à 5.
Les résultats me paraissent carrément, bon, surtout quand on voit le temps investi pour que la version Cython soit propre.
Ce qui est sympa avec PyPy, c'est qu'il y a encore pas mal de gains de performances attendus. Il vont encore rajouter des spécialisations pour cetains types dans le futur, et ils ont encore visisblement quelques idées de plus pour que ça tourne de plus en plus vite…
[^] # Re: Pypy
Posté par Philippe F (site web personnel) . En réponse au journal pythran: python -> c++. Évalué à 3.
Je le pense aussi.
A lire les derniers blogs, je pense que PyPy devrait mouliner ton code pour l'optimiser à mort. Et le gros avantage par rapport à ton projet:
1. il est déjà écrit
2. il support l'ensemble complet de Python
[^] # Re: Sublime Text 2 & Solarized
Posté par Philippe F (site web personnel) . En réponse au journal De tout, de rien, des bookmarks, du bla bla. Évalué à 3.
Je viens de découvrir cet éditeur et j'en suis sur le cul (sauf que j'étais déjà assis … mais passons). Je cherchais un remplaçant potable à Notpad++ mais sans succès pour l'instant.
Et dire qu'il existe un éditeur :
- beau visuellement
- supportant un mode Vim (c'est hyper rare que ça marche bien et là, c'est un binding de qualité)
- extensible en python, mon langage préféré
- simple claire et rapide
Comment se fait-il que je n'en ai jamais entendu parlé ? Je vais tester pendant quelques semaines et je me fendrai peut-être de 60$ pour financer un logiciel—certe propriétaire—mais bien codé et de bonne qualité !
Ca fait longtemps que ça existe cet éditeur ? Et c'est one-man project j'imagine ?