vlamy a écrit 751 commentaires

Ça marche très bien en France aussi en fait :)

Parfois un appel est émis sous mes yeux.
Par exemple je fais défiler le carnet d'adresses. Souvent il ne défile pas (bug ?). Je glisse le doigt dans un sens ou l'autre, il reste figé. Par réflexe je lève puis repose le doigt… et toc un appel est émis. Alors que si le carnet d'adresses n'est pas bloqué, poser le doigt ne lance pas un appel.
Une fois l'appel lancé… le gros bouton rouge ne permet pas de le couper. Je vois sous mes yeux l'appel se faire et impossible de le couper. Je peux appuyer autant que je veux dessus, rien. Appuyer sur le bouton marche/arrêt ne coupe pas la communication non plus.

Sans les moufles ça marche mieux :)
Plus sérieusement (désolé pour la blague mais la perche était trop tentante), je pense que ce problème vient davantage de l'interface doigts/téléphone que de l'OS.

Pas vraiment tout seul. C'est en le mettant dans ma poche. Si par malheur j'oublie de le verrouiller, presque à chaque fois un appel est émis.
Il est absolument impératif de penser à le verrouiller à chaque fois. Ou de ne surtout pas toucher l'écran (facile, il recouvre 100% de la surface).

C'est effectivement un impératif (encore une fois, je ne pense pas que ça soit la faute de l'OS) ! Je crois même que le verrouillage par défaut est assez rapide (< 30 secondes d'inactivité).

Bon, clairement moins bien et moins pratique que ce qui existait en 1996 ou 1997 sur Palm. Donc en gros c'est nul puisque moins bien qu'un truc qui a 15 ans.

C'est le discours que j'entends beaucoup en ce moment de la part de développeurs mobile, à propos de plateformes hétérogènes. Je n'ai pas d'analyse précise (trop jeune pour avoir connu plam OS), mais ta critique est sûrement vraie.

Par abus de langage on parle aussi d'évènements atomiques. Par exemple, une diffusion de message atomique est une diffusion totalement ordonnée, c.à.d. grossièrement un broadcast pour lequel tous les destinataires traitent les messages dans le même ordre. C'est beaucoup utilisé pour la réplication de base de données, par exemple, pour assurer que tous les répliquas sont dans le même état.

Mon code est trop complexe pour un debugger :)
Plus sérieusement je fais essentiellement de l'implémentation de protocole, donc du code distribué et les bugs se situent, dans 90% des cas, dans l'état partagé du système (variables désynchronisées, deadlock distribué,…etc). Et là le debugger est généralement inutile, du coup je suis habitué à utiliser des traces dans les logs, et j'utilise un outil maison pour fusionner les logs de plusieurs machines. Je vous passe les problématiques de causalité, ordre total,…etc

C'était juste pour donner un exemple légitime de cas où le debugger n'est pas à la hauteur.

en ce qui concerne la musique — et bien d'autres activités — l'écoute — ou toute autre attitude passive — n'est pas nécessairement ce qui présente le plus d'intérêt.

Attention tout de même à distinguer écoute passive et écoute active. La dernière pouvant notamment impliquer une participation du public dans un concert, une simple présence de l'auditeur qui stimule l'artiste ou plus simplement : des commentaires des auditeurs (je pense particulièrement à l'écoute sur les plateformes de diffusions à la Deezer, Soundcloud ou autres).

Cette écoute active participe à, voir est le pilier de, la culture musicale !

Occasionnellement, un concert c'est pas mal non plus. Histoire de stimuler cette culture.
Je dis occasionnellement, parce qu'aujourd'hui je suis un vieux con de père de famille avec toutes les obligations joies que ça implique, mais à une époque je faisais largement un concert par semaine. Et là j'avais l'impression de participer à ce que vous appelez culture (en tant que simple auditeur).

Je siffle aussi dans mon coin, mais je n'ai pas la prétention d'appeler ça de la musique :)

Ou plus sérieusement :

• Sur l'ordi de boulot avec un casque raisonnable (Wesc à moins de 100 euros). Je fais partie de ces gens qui aiment bosser avec un casque sur les oreilles, afin de s'immerger dans son monde de développeur. Mais faut un casque super confortable pour ça ! Mes sources :
  • Disque dur : achats d'album au format flac (des fois qu'un jours je sois assez riche pour accéder à de la haute fidélité) sur cd1d ou des fois Starzik. J'avoue posséder environ 10% de mp3 piratés (copiés depuis le CD du cousin de la tante de l'ami Henri) et je ne m'en cache pas, étant content d'acheter 90% de ce que j'écoute.
  • L'excellent Soundcloud :).
  • Deezer avec abonnement.
  • Quelques radios diverses et variées.
• Des CD dans ma vielle Clio (10 min par jour)
• Des vinyles occasionnellement chez des amis platinistes.

Ça serait pas Chromium qui lancerait salement Thunderbird pour une raison lambda (un lien mailto par exemple)?

Pour l'exemple, jette un oeil sur mon site web, il est moche hein? :-D

Moche je ne sais pas, mais pas à jour en tous cas :)

Vous pouvez toujours contribuer à MediaInfo en faisant autre chose :
…
Adapter pour des plates-formes non supportées ( Linux , Win64…)
…

MediaInfo 0.7.4.0 sous Linux de Novembre 2006 !

(On m'appelle le crawler, je suis un bot en fait)

Je vais donner ma conclusion dés le départ : « le travail c'est avant tout alimentaire ».

Pour faire cours : je m'épanouis vraiment dans mon taff, je me sens valorisé, il y a un vrai challenge,etc. J'estime vraiment être bien loti de ce côté là. Et pourtant, même si j'adore ce que je fais au boulot, je m'aperçois qu'il y a toujours des trucs qui me passionnent en dehors de mon boulot et dont je n'arriverais pas à me passer (apprendre Ruby, faire un joli site Web, développer ma lib pour le WM Awesome,..etc).

Ma conclusion : ne pas mélanger passion et travail. Même si travail et passion peuvent se chevaucher et si ça peut arriver de bosser le soir à la maison par passion : il ne faut pas en faire une habitude.
A noter qu'il existe des cas particuliers (chercheurs, job de rêves, dev. Goggle,..etc) qui peuvent faire exception, mais ils sont rares et ce n'est pas systématique.

Et ce que je ressens vis à vis de ça, beaucoup de gens d'expérience me l'ont confirmé.
Anecdote : j'ai eut le privilège de discuter avec Alain Robert (cas typique du gars qui privilégie sa passion avant tout), et même lui arrive à cette conclusion avec l'âge.

En gros, ça veut dire que tout change : ton job, tes goûts, ta situation sociale, mais une chose reste : il faut bosser pour se nourrir. Donc si tu n'arrive pas à te passionner de ton boulot, je te conseillerai de garder tes passions pour t'épanouir à côté, quitte à baisser tes exigences vis à vis de ton job et à l'aménager un peu (80%, mouler en douce sur DLFP,…etc).

Je ne connais pas assez bien Python, mais il me semblait bien que ce genre d'outil existait. Il parait assez clair que c'est la solution propre.

Pas tant que ça, dès lors que l'on connaît les dépendances du dit logiciel. Ou alors, tu ne parles des fichiers deb… (cf plus haut ou j'explique comment j'ai fait un truc à la va-vite…)

J'entends de faire un paquet par dépendances :)

Mais cela dit, je suis d'accord sur le fait qu'il vaut mieux avoir un paquet qui embarque toutes les dépendances que pas de paquet du tout. Dans ce cas, je ferais juste attention à utiliser un environnement spécifique pour le logiciel en question, afin que les libs embarquées ne polluent pas l'environnement de l'utilisateur (Par chance, Python se prête très bien à ce genre de gymnastique). Je pense au cas où on installe une lib embarquée avec un logiciel arbitraire, puis qu'on installe cette même lib par la suite via le gestionnaire de paquet. Ça m'est déjà arrivé en Java et c'est assez subtile à trouver comme bug !

Finalement on a trouvé une solution assez propre pour Paperwork :) Y a plus qu'à !

Au final on est d'accord sur la technique, je suis d'accord sur le fait que la plupart des dépendances doivent être packagées à part. Pour les OS proprio je suis d'accord aussi.

Je voulais juste montrer que c'était dur de faire un paquet de ce logiciel. Et honnêtement, je pense que si tu te fends de faire un paquet Debian pour ta V1 et que tu repasses demander des testeurs, tu auras beaucoup plus de succès. Y compris auprès des non debianistes :)

Mais là non , son logiciel est situé à la toute fin de la chaîne des dépendances, il est construit autour des gestionnaires de paquets, et pourtant il doit faire l'inverse pour être éventuellement intégrable.

« Autour d'apt-get » serait plus juste.

On peut même imaginer que sans le gestionnaire de paquets pour rapidement lui fournir un environnement de développement lui permettant de ce concentrer sur sa valeur ajoutée,
le logiciel n'aurait jamais vu le jour.

Ça n'empêche pas qu'on va vouloir le tester avant de l'injecter dans les dépôts officiels.

Par contre, une fois la 1ère release faite, j'ai l'intention d'aller discuter avec les mainteneurs Debian, pour voir si l'un d'entre eux serait assez charitable pour packager Paperwork et quelques-unes de ses dépendances. (pourquoi Debian ? Parce-que c'est la distribution que j'utilise). Si l'un d'entre eux le fait, tant mieux, sinon tant pis.

Entre un logiciel facilement portable et un logiciel dédié Debian, les mainteneurs Debian auront vite fait leur choix je pense. Bon, faudrait-il encore qu'il existe un concurrent sérieux à Paperwork (en fait, j'en sais rien). Mais tout ça pour montrer que la portabilité de ton logiciel va aussi dans l'intérêt de la communauté Debian.

En même temps, je n'ai jamais formulé ça de cette façon. Ce que je disais était "si j'ai beaucoup de dépendances, c'est parce-que je ne veux pas réinventer la roue". La question de les embarquer / packager avec Paperwork ne m'a jamais été posée jusque là.

Mea culpa ! Effectivement la question n'était pas posée comme ça, mais finalement l'utilisateur s'en fout un peu qu'il y est beaucoup de dépendances, si le logiciel est facile à installer, est à jours, et fonctionne correctement.

Quoiqu'il en soit, je continue à penser que les dépendances sont un problème qui se résoudra tout seul grâce aux gestionnaires de paquets. Si les packageurs font leur travail, un simple "apt-get install paperwork" (par exemple) suffira à l'installer.

Je rejoins Zenitram sur le fait que si tu attends que ça tombe du ciel, tu vas freiner l'adoption de ton logiciel.

Mais dans l'ordre des choses, le packaging et la distribution de Paperwork ne sont pas de mon ressort.

Pour moi, ça veut dire que tu n'as pas envie de faire le packaging (ça je crois qu'on l'a bien compris) et que tu t'en fout d'avoir beaucoup d'utilisateurs tant que tu peux faire marcher le projet. J'ai peur que ce genre de politique ne soit pas très vendeur.

Finalement, pour moi le problème majeur est ailleurs : prenons les choses du point de vue d'un packageur potentiel (j'avoue que je me suis posé la question, mais je suis moyennement motivé):

• 13 dépendances à packager : c'est énorme ! Allez, disons que 4 ou 5 sont déjà disponibles sur les dépôts des principales distrib Linux. Il en reste encore 8 ou 9 ! Et ça pour chaque distrib ciblée. Tu te représentes la quantité de travail? Alors qu'avec un poil de volonté du développeur on pourrait avoir un paquet par distrib à faire. Même si le problème des dépendances est difficile (j'ai pas de solution miracle), ça donne moyennement envie.
• Portabilité ? : Le logiciel est en Python, donc il pourrait potentiellement viser Windows et/ou Mac OS. Oui mais avec la gestion actuelle des dépendances, c'est déjà un boulot de titan de le packager pour des distribs non debian. La encore je suis un peu déçu.
• Gestion du projet : La gestion des dépendances (Quelles libs on utilise? Quelles libs on peut virer? Quelles versions?), c'est le développeur qui doit les faire, j'espère qu'au moins la dessus on est d'accord. Seulement si le développeur ne tient compte que du code et pas du packaging, le logiciel peut vite devenir une horreur à packager. Par exemple si le dev choisi d'intégrer une lib originale que personne n'utilise à chaque release.
• Le côté ingrat du boulot : Finalement, je préfère largement coder que packager, et je suis sûr que c'est le cas d'une majorité de gens. Donc si le travail n'est pas préparé par le project leader et qu'il n'est même pas valorisé, il y a peu de chance que je le fasse.

Encore une fois, je salue ton travail car il y a du mérite ! Mais je pense que mes critiques sont fondées, en tout cas c'est la réflexion que je me suis faite. Bref le problème du packaging est difficile dans ton cas, en plus c'est du Python et c'est pas le moment adéquate pour vendre du Python. Mais je suis sûr qu'en y mettant les formes et en fournissant un peu de travail, tu peux arriver à un résultat très prometteur.

Salut, comme je l'avais mentionné dans un précédent journal, j'ai essayé d'installer paperwork sur une distribution Linux non basée sur Debian (Archlinux en l'occurrence) et j'ai décidé d'abandonner à cause du problème des dépendances. Étant un gars plutôt acharné et têtu, je pense que si j'en suis arrivé là, d'autres arriveront à la même conclusion, alors je développe ma critique dans l'intérêt de ce projet, que je trouve très intéressant malgré le fait que j'ai abandonné son adoption. Voici les éléments par ordre d'importance qui m'ont fait abandonner le projet "paperwork" :

• Installation très fastidieuse : développant en Python 3, j'ai pas mal de libs compatibles Python 3 et là on part sur du Python 2 (je ne critique pas ce fait que je comprend très bien). J'ai donc 13 libs à installer, dont la plupart directement depuis les sources. c.-à-d. sans gestionnaire de paquet. Et là du coup je m'aperçois du point 2.
• Certaines des dépendances sont abandonnées en upstream. Soit pour passer à Python 3, soit tout simplement abandonnées (J'ai nettoyé mon système depuis le tentative d'installation, alors je n'ai pas les détails, mais on pourra creuser ensemble).
• Je fait le calcul rapide « investissement pour l'installation/temps que je vais en profiter » avant qu'une MAJ ne fasse péter mon installation : et je me dis que je n'ai pas le courage.

Mais je n'abandonne pas là car je vois que le projet est vivant et toujours très intéressant.
Étant également développeur de métier, je me permet de critiquer l'argument suivant :

« Je n'embarque pas les dépendances, car je ne veux pas ré-inventé la roue ».

Ta formulation est mauvaise, car tu peux très bien embarquer des releases des dépendances, qui à priori sont libres et compatibles avec la licence de ton logiciel. Donc si tu veux fournir un logiciel qui s'installe simplement (en exécutant un seul script) tu peux le faire ! C'est un peu de boulot, mais tu ne ré-inventeras rien du tout.

Mais bien que mal justifié pour moi, ton choix se défend quand même, car les dépendances sont inévitable (OCR, SANE…etc) et là c'est tout le problème du développement en générale qui se pose : «  Dois-je garder des dépendances 100% à jours, ou travailler avec des releases vieillissantes? ». Je n'ai pas la réponse à cette question, car c'est une histoire de compromis. Mais ce qui est sûr, c'est que ton logiciel est difficile à installer, et que ça va incroyablement freiner son adoption. Ce qui, d'après ce que j'en ai vu, est très dommage.

Defense Distributed also inserts a strip of metal into the gun to make sure metal detectors pick it up.
But, as Greenberg points out the people that print out the design might not be inclined to put metal strips in their guns, thus making them much harder to detect.

En plus de ça l'arme peut devenir quasiment indétectable.

Non des murs propriétaires :)

Je suis aussi sceptique que toi sur la rentabilité des imprimantes 3D, mais c'est pas pour ça que je veux les contrôler avec des DRM. La question est de laisser le choix du libre ou non. En gros, si tu établis un patron pour un joli porte clef, les DRM te permettront de devenir propriétaire de ce patron (de ce que j'en ai compris). Donc on repart dans le principe des brevets logiciels avec toutes les aberrations que ça implique.

D'ailleurs la mauvaise utilisation accidentelle d'une imprimante 3D ne devrait pas avoir les conséquences de la mauvaise utilisation accidentelle d'un fusil, même d'un fusil "pour enfant"

Tu fais référence à cet accident ?

À la faveur de l'imprimante, je doute que le gamin de 5 ans sache construire une arme avec une imprimante 3D. C'est une question de business, c'est tout ! Tu imagines : un outil qui permettrait à madame Michou de construire ce qu'elle veut à partir de plans libres, c'est de la folie ! On fait comment après pour exploiter cette pauvre madame Michou, si elle est autonome (modulo les matières premières)?

Le prétexte de la construction d'arme est un argument marketing pour imposer les DRM. Et ça exploite tellement bien notre nature paranoïaque, qu'il y a des chances pour que ça passe dans pas mal de pays. C'est petit de défendre les DRM de cette façon, mais c'est sûrement la plus simple et la moins couteuse.

Je suis plus Mame que Steam, pour donner une idée, et dans ce domaine Linux va très bien !

Hélas je ne fais pas partie des gens qui s'épanouissent à 100% avec des jeux vidéos. En particulier ça a du mal à remplacer le sport ou l'activité physique dans mon mode de vie. Ce qui ne m'empêche pas d'aimer certains jeux (et là effectivement je suis plus jeux de baston ou doomlike).

Ben en fait, ça permet de trancher : si tu n'es pas capable de balancer 5 k€ d'un coup, ne surtout pas s'engager dans l’immobilier, car 5k€ ça peut te tomber du jour au lendemain à payer sous 3 mois (genre une poutre porteuse qui se casse la gueule dans l'immeuble, toute ressemblance avec la vraie vie serait un hasard ;-) ).

Tu as raison, mais formulé ainsi tu vas faire peur aux acquéreurs potentiels. Déjà, la plupart des assurances prennent en charge les poutres qui tombent. Mais ça peut ne pas être le cas, j'en conviens. Ensuite, même si tu ne peux pas sortir l'argent comme ça, en générale les banques te prêtent de l'argent. Après tout elle sont solidaires sur le capital, au moins pour le début.

Finalement ta remarque est valable sur un plan plus large : si tu casses ta voiture, tu paieras moins cher si tu as le cash que si tu dois emprunter pour en acheter une autre (si tu en as la capacité au moment de l'accident). Idem pour les prothèses dentaires, lunettes, handicaps de la vie …etc. Et ne nous plaignons pas, en France on est pas les plus mal lotis.

Quand on est proprio, on n'a plus que des charges en plus de l'emprunt à gérer…

J'avais compris ton propos te travers, alors je me permet de corriger.