Le crash d'une plateforme d'échange ne me choque pas plus que ça, en fait. Ce risque est inhérent à n'importe quelle plateforme centralisée, quel que soit le bien sous-jacent qui est échangé, Bitcoins ou autre.
Ce qui me gêne, par contre, avec Bitcoin, c'est l'avantage déraisonnable qui est donné aux premiers entrants.
La courbe d'émission des Bitcoins est connue (et inhérente au concept de Bitcoin) :
Presque la moitié des Bitcoins ont déjà été émises. Si Bitcoin devait devenir la monnaie de référence et remplacer toutes les autres monnaies, cela signifierait que les détenteurs actuels de Bitcoin possèderaient la moitié de la richesse mondiale.
Il faut être quand même un peu cinglé pour croire que les "vrais" détenteurs de la moitié de la richesse mondiale vont accepter de se faire déposséder de leur propriété par la poignée de détenteurs actuels de Bitcoin.
Il y aura donc forcément un moment où le transfert de richesses vers les premiers entrants devient si scandaleux que plus personne n'entrera dans le système. Ce jour-là, ce sera le crash.
Juste une petite note pour indiquer que je viens de convertir les musiques au format ogg. Pour varier un peu les ambiances, j'ai aussi ajouté une nouvelle musique trouvée sur opengameart : http://opengameart.org/content/lah
Elle est maintenant utilisée pour les niveaux black and white.
Je l'ai testé sous Ubuntu 12.04 64 bits et Kubuntu 13.10 64 bits. Normalement, il fonctionne sans l'astuce du lien symbolique. La seule dépendance requise par rapport à un système "standard" est le paquet libqtmultimedialib1.
Même pour un journal bookmark, ce serait sympa d'expliquer en quelques mots ce qu'est Nagios. Parce que là, non seulement je ne savais pas avant de cliquer, mais je ne savais toujours pas après …
Pour ceux qui se posent la question, Nagios est donc un programme de surveillance système et réseau.
Je n'ai pas envie de m'embêter à chercher où le poster sur framasoft, du coup je l'indique ici. Dans l'interview (que j'ai lu avec intérêt, d'ailleurs), il y a une typo : le mot correct, c'est procrastination. Je le sais, je suis un expert du domaine.
Certes, ce genre de constructions en C est possible, mais ça ne fait pas du C un langage de programmation objet pour autant. La dérivation de classes du C++ est interne au langage, alors que là, c'est de la gestion manuelle.
Le problème des constructions manuelles, c'est qu'elles ont vite leur limite. Là, l'exemple ne marche que parce que struct A est en tête de struct B. Si on veut une structure qui hérite de deux structures, et non plus d'une seule, il va falloir faire des manipulations de pointeur horribles pour que les casts soient effectués sur les bons emplacements mémoire. Ce qui mènera probablement à un code difficile à comprendre.
En fait, plutôt que de choisir un langage, on choisit plutôt des bibliothèques sous-jacentes, et souvent le choix du langage en découle. Par exemple, dans mon cas, j'utilise en général la bibliothèque Qt dès qu'il y a besoin de faire un GUI, et donc, le C++ est le choix naturel.
Par contre, si c'est la bibliothèque Gtk qui est utilisée pour le GUI, le choix du C est possible.
Sinon, tu as l'air de dire que tu as besoin de "gérer de l'héritage". Si tu parles de l'héritage au sens de la programmation objet, il n'y a pas vraiment matière à hésiter entre C et C++, car seul le C++ fournit des mécanismes de manipulation du concept d'héritage.
Moi aussi, ça m'a horrifié quand j'ai vu la proportion de glucides de leur régime alimentaire. C'est vraiment de mauvais goût de blaguer alors que tous ces prisonniers risquent des problèmes de diabète ou d'obésité.
J'ai bien aimé les détails pratiques sur les différences culturelles, par exemple sur les entretiens d'embauche.
Par contre, si ton but était d'éveiller des vocations, c'est un peu raté, parce qu'à partir du moment où tu rentres en France, tu n'es plus vraiment crédible. L'impression qui se dégage de ton post, c'est qu'au bout du compte, la vie culturelle est plus importante que le boulot… ce qui est un choix tout à fait respectable, d'ailleurs.
En tout cas, un candidat qui me dirait en entretien qu'il n'utilise jamais d'ide parce que vim c'est mieux que tout, je ne l'embauche surtout pas. Trop compétent pour le poste…
D'abord, bon courage, car ce type de passage à vide n'est jamais facile à surmonter.
Je ne crois pas qu'il y ait une recette magique, mais dans ton cas, la devise shadock est peut-être bonne conseillère : s'il n'y a pas de solution, il n'y a pas de problème.
Je ne dis pas ça pour te décourager encore plus. Au contraire, je suis sûr qu'il y a quelque part un boulot qui te conviendrait mieux que celui actuel. Malheureusement, ce n'est jamais facile à trouver. Et ça l'est encore moins quand on est déjà fatigué psychologiquement comme tu le décris.
Du coup, une solution pour l'instant, c'est d'arrêter de chercher un autre boulot. Contente-toi de ton boulot actuel provisoirement, oublie un peu tout ça, démarre des activités nouvelles (livres, sport, musées, films), essaye de rencontrer de nouvelles têtes (club, association). Et dans quelques mois, quand tu auras rechargé les piles, tu pourras sans doute réfléchir de nouveau à ton avenir professionnel sereinement.
Sinon, un conseil concret pour ta recherche de boulot (mais pas pour maintenant, hein, pour dans quelques mois). Apparemment, on t'a fait des propositions (dev php) qui ne correspondent pas à tes attentes. Ça, c'est une conséquence classique du cv "général" qui ne vise pas un poste assez précis. Si tu ne veux pas faire de dev php, il ne faut pas que ton cv donne l'impression que tu en es capable. Un bon cv ne doit pas donner l'impression que tu es capable de faire plein de choses. Au contraire. Dans l'idéal, il doit donner l'impression que tu n'es capable de faire qu'une seule et unique chose : celle du poste qui t'intéresse vraiment.
Ce type de malware relance l'intérêt d'avoir une chaîne de binaires entièrement signés, en particulier sur les serveurs. Les drms sont un problème quand ils sont utilisés pour limiter les possibilités de l'utilisateur contre son gré, mais ils seraient au contraire bien utiles pour limiter ce type d'attaques.
J'ai un peu l'impression que c'est se tirer dans le pied que de s'éparpiller sur d'autres plateformes quand on a déjà du mal avec une seule, mais c'est débattable.
Sur ce point, personnellement, j'ai l'impression inverse. C'est presque toujours une bonne idée d'être multi-plateforme. Cela permet d'augmenter la base d'utilisateurs, et donc le nombre de retours sur les bugs, le nombre de traducteurs, etc.
J'aimerais que les proportions soient inversées, mais par exemple sur les logiciels que je développe (en particulier Kitsune, sur lequel j'ai plus de recul que Flukz), la proportion d'utilisateurs est typiquement 70% windows, 20% linux, et 10% mac.
A propos de l'incompatibilité gtk2/gtk3, le développeur de pcmanfm indique même que dans son cas il était plus facile de migrer de gtk2 à Qt que de gtk2 à gtk3 : "Ironically, fixing all of the broken compatibility is even harder than porting to Qt in some cases (PCManFM IMO is one of them)." (http://blog.lxde.org/?p=990 )
D'ailleurs les threads ont été rajoutés très tardivement dans Qt, genre dans Qt 3. Et globalement, ca reste peu recommandé.
Euh… J'utilise régulièrement les threads Qt, et ça marche très bien. Pour une application de calcul (scientifique ou autre) avec une interface graphique, par exemple, je pense même que Qt est un très bon choix.
En tout cas, ils doivent en avoir vraiment marre de gtk pour prendre une telle décision, parce que migrer de gtk à Qt un logiciel autant avancé, c'est un travail énorme. Il y a forcément des parties du logiciel qu'il faudra réécrire quasiment de zéro.
Un inconvénient des templates, c'est la difficulté de compréhension du code. Sur une échelle de 1 à 10 en compétence C++, je me note à disons 8, et j'ai toujours autant de mal à comprendre les templates dès qu'ils sont un peu subtils comme ici. Autant dire que pour le commun des mortels, c'est juste du charabia imbuvable. Donc à éviter si possible.
Sinon, honnêtement, avant d'implémenter un visiteur, il faut commencer par se demander si on n'a pas un problème de design de l'architecture des classes. Et si on n'en a pas, attendre le lendemain matin, et se reposer la question une seconde fois…
J'ai vu du code dans beaucoup de contextes différents (entreprise, université, logiciel libre communautaire), pas mal de langages (C++, C#, Perl, php, …), et plusieurs langues natives différentes aussi (français, anglais, japonais).
Dans tout ça, c'est bien simple, j'y ai retrouvé partout la grande équation de l'informatique : la durée de vie d'un projet est directement liée à la qualité du code, et les commentaires en sont une composante importante. Les projets avec de mauvais commentaires meurent plus vite que les autres.
Par contre, j'inclus le choix des noms de variables dans la qualité des commentaires. Une variable bien nommée, c'est déjà une forme de commentaire du code. Et dans certains cas c'est même suffisant (mais pas toujours).
Bref, il n'y a même pas besoin de se battre sur la nécessité ou non des commentaires. Ceux qui ne commentent pas ne le savent peut-être pas encore… mais ils sont déjà morts.
# Limites du système pyramidal
Posté par Yukito (site web personnel) . En réponse au journal Bitcoin, le début de la fin?. Évalué à 10.
Le crash d'une plateforme d'échange ne me choque pas plus que ça, en fait. Ce risque est inhérent à n'importe quelle plateforme centralisée, quel que soit le bien sous-jacent qui est échangé, Bitcoins ou autre.
Ce qui me gêne, par contre, avec Bitcoin, c'est l'avantage déraisonnable qui est donné aux premiers entrants.
La courbe d'émission des Bitcoins est connue (et inhérente au concept de Bitcoin) :
http://commons.wikimedia.org/wiki/File:Total_bitcoins_over_time.png
Presque la moitié des Bitcoins ont déjà été émises. Si Bitcoin devait devenir la monnaie de référence et remplacer toutes les autres monnaies, cela signifierait que les détenteurs actuels de Bitcoin possèderaient la moitié de la richesse mondiale.
Il faut être quand même un peu cinglé pour croire que les "vrais" détenteurs de la moitié de la richesse mondiale vont accepter de se faire déposséder de leur propriété par la poignée de détenteurs actuels de Bitcoin.
Il y aura donc forcément un moment où le transfert de richesses vers les premiers entrants devient si scandaleux que plus personne n'entrera dans le système. Ce jour-là, ce sera le crash.
# Format ogg
Posté par Yukito (site web personnel) . En réponse au journal Flukz 0.4. Évalué à 1.
Juste une petite note pour indiquer que je viens de convertir les musiques au format ogg. Pour varier un peu les ambiances, j'ai aussi ajouté une nouvelle musique trouvée sur opengameart : http://opengameart.org/content/lah
Elle est maintenant utilisée pour les niveaux black and white.
[^] # Re: Archlinux
Posté par Yukito (site web personnel) . En réponse au journal Flukz 0.4. Évalué à 1.
Merci, ça va me motiver à travailler pour continuer d'améliorer tout ça.
[^] # Re: Kubuntu Saucy 64bits.
Posté par Yukito (site web personnel) . En réponse au journal Flukz 0.4. Évalué à 1. Dernière modification le 24 février 2014 à 07:05.
Ok, je vois. Il y a de subtiles différences dans les noms des librairies…
Du coup, je viens de compiler un binaire sous Ubuntu 64 bits : http://download.tuxfamily.org/flukz/flukz0.4_ubuntu64
Je l'ai testé sous Ubuntu 12.04 64 bits et Kubuntu 13.10 64 bits. Normalement, il fonctionne sans l'astuce du lien symbolique. La seule dépendance requise par rapport à un système "standard" est le paquet libqtmultimedialib1.
[^] # Re: Déprimant
Posté par Yukito (site web personnel) . En réponse au journal [Trolldi] Le langage plus approprié pour écrire des applications graphiques multiplateformes. Évalué à 4.
C'est parce que la majorité des développeurs sont contents de la version native C++ de Qt. Et donc le besoin de bindings est limité.
[^] # Re: Quelques explications
Posté par Yukito (site web personnel) . En réponse au journal [Bookmark] Nagios fork. Évalué à 2.
Ah ben c'est malin. J'ai essayé pour voir de quoi tu parlais, et maintenant c'est tout bloqué. On fait comment pour quitter ?
# Quelques explications
Posté par Yukito (site web personnel) . En réponse au journal [Bookmark] Nagios fork. Évalué à 3. Dernière modification le 25 octobre 2013 à 13:44.
Même pour un journal bookmark, ce serait sympa d'expliquer en quelques mots ce qu'est Nagios. Parce que là, non seulement je ne savais pas avant de cliquer, mais je ne savais toujours pas après …
Pour ceux qui se posent la question, Nagios est donc un programme de surveillance système et réseau.
# Société Moulinsart
Posté par Yukito (site web personnel) . En réponse au journal Tintin tombera-t-il un jour dans le domaine public ?. Évalué à 8. Dernière modification le 22 octobre 2013 à 15:25.
Je ne sais pas pour 2052, mais en tout cas les ayants-droits actuels sont bien connus pour leur ouverture d'esprit :
# Chipotage
Posté par Yukito (site web personnel) . En réponse à la dépêche This is the end : GKND tome 5. Évalué à 2.
Je n'ai pas envie de m'embêter à chercher où le poster sur framasoft, du coup je l'indique ici. Dans l'interview (que j'ai lu avec intérêt, d'ailleurs), il y a une typo : le mot correct, c'est procrastination. Je le sais, je suis un expert du domaine.
# Cuisine, recettes, tout ça
Posté par Yukito (site web personnel) . En réponse au journal Ada Lovelace day 2013, le bilan. Évalué à 4.
L'absence de femmes en informatique est d'autant plus surprenante qu'il est bien connu qu'elles sont douées pour la cuisine. -->[]
[^] # Re: mourrir ?
Posté par Yukito (site web personnel) . En réponse au journal Octobre est vraiment Rouge pour Tom Clancy. Évalué à 1.
Ah, cherche pas, ça veut juste dire pourrir, mais c'est facile de déraper sur le clavier.
[^] # Re: des détails
Posté par Yukito (site web personnel) . En réponse au journal C(++) ?. Évalué à 2.
Certes, ce genre de constructions en C est possible, mais ça ne fait pas du C un langage de programmation objet pour autant. La dérivation de classes du C++ est interne au langage, alors que là, c'est de la gestion manuelle.
Le problème des constructions manuelles, c'est qu'elles ont vite leur limite. Là, l'exemple ne marche que parce que struct A est en tête de struct B. Si on veut une structure qui hérite de deux structures, et non plus d'une seule, il va falloir faire des manipulations de pointeur horribles pour que les casts soient effectués sur les bons emplacements mémoire. Ce qui mènera probablement à un code difficile à comprendre.
[^] # Re: des détails
Posté par Yukito (site web personnel) . En réponse au journal C(++) ?. Évalué à 4.
En fait, plutôt que de choisir un langage, on choisit plutôt des bibliothèques sous-jacentes, et souvent le choix du langage en découle. Par exemple, dans mon cas, j'utilise en général la bibliothèque Qt dès qu'il y a besoin de faire un GUI, et donc, le C++ est le choix naturel.
Par contre, si c'est la bibliothèque Gtk qui est utilisée pour le GUI, le choix du C est possible.
Sinon, tu as l'air de dire que tu as besoin de "gérer de l'héritage". Si tu parles de l'héritage au sens de la programmation objet, il n'y a pas vraiment matière à hésiter entre C et C++, car seul le C++ fournit des mécanismes de manipulation du concept d'héritage.
[^] # Re: Facile
Posté par Yukito (site web personnel) . En réponse au journal "Pussy Riot. Lettre du camp 14 de Mordovie". Évalué à 10.
Moi aussi, ça m'a horrifié quand j'ai vu la proportion de glucides de leur régime alimentaire. C'est vraiment de mauvais goût de blaguer alors que tous ces prisonniers risquent des problèmes de diabète ou d'obésité.
# pas si mal, la France
Posté par Yukito (site web personnel) . En réponse au journal Aller bosser à San Francisco. Évalué à 3.
J'ai bien aimé les détails pratiques sur les différences culturelles, par exemple sur les entretiens d'embauche.
Par contre, si ton but était d'éveiller des vocations, c'est un peu raté, parce qu'à partir du moment où tu rentres en France, tu n'es plus vraiment crédible. L'impression qui se dégage de ton post, c'est qu'au bout du compte, la vie culturelle est plus importante que le boulot… ce qui est un choix tout à fait respectable, d'ailleurs.
# question à l'entretien
Posté par Yukito (site web personnel) . En réponse au journal Point de vue : un IDE est il un outil de programmation indispensable ?. Évalué à 3.
En tout cas, un candidat qui me dirait en entretien qu'il n'utilise jamais d'ide parce que vim c'est mieux que tout, je ne l'embauche surtout pas. Trop compétent pour le poste…
# Oublie un peu tout ça
Posté par Yukito (site web personnel) . En réponse au journal [HS] Développeur un peu perdu… ou pas… Que faire maintenant ? Changer de vie ?. Évalué à 8.
D'abord, bon courage, car ce type de passage à vide n'est jamais facile à surmonter.
Je ne crois pas qu'il y ait une recette magique, mais dans ton cas, la devise shadock est peut-être bonne conseillère : s'il n'y a pas de solution, il n'y a pas de problème.
Je ne dis pas ça pour te décourager encore plus. Au contraire, je suis sûr qu'il y a quelque part un boulot qui te conviendrait mieux que celui actuel. Malheureusement, ce n'est jamais facile à trouver. Et ça l'est encore moins quand on est déjà fatigué psychologiquement comme tu le décris.
Du coup, une solution pour l'instant, c'est d'arrêter de chercher un autre boulot. Contente-toi de ton boulot actuel provisoirement, oublie un peu tout ça, démarre des activités nouvelles (livres, sport, musées, films), essaye de rencontrer de nouvelles têtes (club, association). Et dans quelques mois, quand tu auras rechargé les piles, tu pourras sans doute réfléchir de nouveau à ton avenir professionnel sereinement.
Sinon, un conseil concret pour ta recherche de boulot (mais pas pour maintenant, hein, pour dans quelques mois). Apparemment, on t'a fait des propositions (dev php) qui ne correspondent pas à tes attentes. Ça, c'est une conséquence classique du cv "général" qui ne vise pas un poste assez précis. Si tu ne veux pas faire de dev php, il ne faut pas que ton cv donne l'impression que tu en es capable. Un bon cv ne doit pas donner l'impression que tu es capable de faire plein de choses. Au contraire. Dans l'idéal, il doit donner l'impression que tu n'es capable de faire qu'une seule et unique chose : celle du poste qui t'intéresse vraiment.
# Binaires signés
Posté par Yukito (site web personnel) . En réponse au journal Linux/Cdorked.A : nouvelle backdoor Apache discrète.. Évalué à 4.
Ce type de malware relance l'intérêt d'avoir une chaîne de binaires entièrement signés, en particulier sur les serveurs. Les drms sont un problème quand ils sont utilisés pour limiter les possibilités de l'utilisateur contre son gré, mais ils seraient au contraire bien utiles pour limiter ce type d'attaques.
[^] # Re: Le positionnement d'OpenShot et PiTiVi
Posté par Yukito (site web personnel) . En réponse au journal OpenShot abandonne Gtk+.... Évalué à 1.
Sur ce point, personnellement, j'ai l'impression inverse. C'est presque toujours une bonne idée d'être multi-plateforme. Cela permet d'augmenter la base d'utilisateurs, et donc le nombre de retours sur les bugs, le nombre de traducteurs, etc.
J'aimerais que les proportions soient inversées, mais par exemple sur les logiciels que je développe (en particulier Kitsune, sur lequel j'ai plus de recul que Flukz), la proportion d'utilisateurs est typiquement 70% windows, 20% linux, et 10% mac.
[^] # Re: le fond du problème
Posté par Yukito (site web personnel) . En réponse au journal OpenShot abandonne Gtk+.... Évalué à 3.
A propos de l'incompatibilité gtk2/gtk3, le développeur de pcmanfm indique même que dans son cas il était plus facile de migrer de gtk2 à Qt que de gtk2 à gtk3 : "Ironically, fixing all of the broken compatibility is even harder than porting to Qt in some cases (PCManFM IMO is one of them)." (http://blog.lxde.org/?p=990 )
[^] # Re: Trollons
Posté par Yukito (site web personnel) . En réponse au journal OpenShot abandonne Gtk+.... Évalué à 3.
Euh… J'utilise régulièrement les threads Qt, et ça marche très bien. Pour une application de calcul (scientifique ou autre) avec une interface graphique, par exemple, je pense même que Qt est un très bon choix.
# Windows
Posté par Yukito (site web personnel) . En réponse au journal OpenShot abandonne Gtk+.... Évalué à 5.
Dans la liste, la raison vraiment importante est probablement le meilleur support des différentes plateformes. Openshot vient en effet de réussir à réunir 40.000 dollars sur kickstarter pour le portage sous windows et mac os : http://www.kickstarter.com/projects/421164014/openshot-video-editor-for-windows-mac-and-linux
En tout cas, ils doivent en avoir vraiment marre de gtk pour prendre une telle décision, parce que migrer de gtk à Qt un logiciel autant avancé, c'est un travail énorme. Il y a forcément des parties du logiciel qu'il faudra réécrire quasiment de zéro.
# un inconvénient des templates
Posté par Yukito (site web personnel) . En réponse au journal Visiteurs en C++. Évalué à 3.
Un inconvénient des templates, c'est la difficulté de compréhension du code. Sur une échelle de 1 à 10 en compétence C++, je me note à disons 8, et j'ai toujours autant de mal à comprendre les templates dès qu'ils sont un peu subtils comme ici. Autant dire que pour le commun des mortels, c'est juste du charabia imbuvable. Donc à éviter si possible.
Sinon, honnêtement, avant d'implémenter un visiteur, il faut commencer par se demander si on n'a pas un problème de design de l'architecture des classes. Et si on n'en a pas, attendre le lendemain matin, et se reposer la question une seconde fois…
[^] # Re: Sélection naturelle
Posté par Yukito (site web personnel) . En réponse au journal To comment or not to comment. That is the question.. Évalué à 1.
Chut, tu vas faire déprimer la moitié des participants…
# Sélection naturelle
Posté par Yukito (site web personnel) . En réponse au journal To comment or not to comment. That is the question.. Évalué à 9.
J'ai vu du code dans beaucoup de contextes différents (entreprise, université, logiciel libre communautaire), pas mal de langages (C++, C#, Perl, php, …), et plusieurs langues natives différentes aussi (français, anglais, japonais).
Dans tout ça, c'est bien simple, j'y ai retrouvé partout la grande équation de l'informatique : la durée de vie d'un projet est directement liée à la qualité du code, et les commentaires en sont une composante importante. Les projets avec de mauvais commentaires meurent plus vite que les autres.
Par contre, j'inclus le choix des noms de variables dans la qualité des commentaires. Une variable bien nommée, c'est déjà une forme de commentaire du code. Et dans certains cas c'est même suffisant (mais pas toujours).
Bref, il n'y a même pas besoin de se battre sur la nécessité ou non des commentaires. Ceux qui ne commentent pas ne le savent peut-être pas encore… mais ils sont déjà morts.