Mais pas d'accord sur ta conclusion : que ça a été un peu tenté ne prouve pas que ça ne marchera jamais.
Je ne vois pas comment ça pourrait le prouver étant donné que Chrome OS (basé sur Linux) et Firefox OS (basé sur Linux) ont tenté ça vraiment et ont réussi pour l'un et va réussir pour l'autre.
Non, le problème c'est que ça a été seulement un peu tenté
Ca n'a jamais été une des 3 priorités essentielles ni de Cannical, ni des autres, eeePC excepté—et encore même eux, on se demande s'ils ont vraiment essayé de faire les choses très très bien… ou s'ils sont seulement servi de GNU/Linux de le temps de montrer que leur concept d'ordinateur d marchait et d'obtenir une grosse ristourne pour Windows XP
En tous cas , moi je pars du principe qu'il faut s'inspirer de ce qu'il se fait de mieux, donc pas de telle distribtuion qui a lancé un modèle avec tel supermarché ; non : s'inspirer de ce qu'a fait Google pour Chrome OS et Mozilla pour Firefox OS
Mieux vaut tard que jamais :)
Cherche dans les archives du blog de Tristan Nitot, il a compris ça depuis très longtemps, et c'est lui qui me l'a fait comprendre.
Le seul moyen d'avoir une distro Linux qui s'installe et s'utilise sans se prendre la tête est un moyen déjà connu et utilisé depuis belle lurette par les constructeurs PC et par Apple: contrôler le matériel!
Je suis d'accord avec toi : c'est une condition nécessaire et non suffisante pour sortir de l'impasse actuelle. Il aurait fallu faire depuis longtemps d'ailleurs (mais bon, on ne peut pas changer le passé). Chrome OS et Firefox OS ont pensé à ça dès le départ, le premier marche très bien et le second, je pense qu'il va très bien marcher aussi. (D'ailleurs je viens de ramener un smartphone Firefox OS de Colombie)
Alors que GNU/linux… ça fait (malheureusement) longtemps que ça m'inspire cette citation d'Albert Einstein :
Insanity: doing the same thing over and over again and expecting different results.
Laisser tomber le mobile (voir plus haut), se focaliser sur ce qu'il avait prévu de faire au début, c'est à dire une distribution Linux que les gens normaux peuvent et ont envie utiliser sans se prendre la tête. Pour cela, travailler main dans la main avec Debian, et se concentrer sur ce qui est important pour les utilisateurs, ce qui est très rarement la même chose que les projets excitants techniquement.
Oui c'est pas gagné, mais comme tu poses la question, je te donne mon avis ;)
Ensuite, pour les gens qui font ça par passion, et j'en fait parti, la reconnaissance des autres est globalement la seule chose qu'on reçoit, donc nier ça en s'appropriant la "gloire" va un peu à l'encontre d'une des motivations primaires.
J'envisageais les choses d'un autre point de vue, mais tu as parfaitement raison là dessus.
Ceci dit, pour moi qui ait un peu envie de démontrer aux incompétents qui trustent les postes de gens sérieux dans l'informatique en France, un succès d'estime ne me suffirait pas ; donc personnellement, si je restais spécialisé dans le mobile, je focaliserais mon énergie et mes maigres talents sur Firefox OS, parce que ça oui, j'y crois beaucoup.
Raison simple : le WEB est le seul système d'exploitation qui a une chance sérieuse de concurrencer iOS (qui va rester important mais décliner) et surtout Android.
C'est la réflexion que je me suis faite après avoir lu cet éditorial[1] de l'étonnant Paul Krugman, qui après avoir été une épine constante[2] de le pied George W Bush, après avoir dénoncé ses confrères économistes "we are in the middle-age of macro-économy"[2] montre en peu de mots à son habitude qu'il a tout compris de l'informatique[1]
[2] Merci à Der Spiegel de me l'avoir fait découvert en 2004. 130 Zeilen Empörung. A l'époque, je pensais naivement que c'était Chirac et Schröder qui embêtaient Bush. Ah ah ah.
[3] The answer, I think, is that we’re living in a Dark Age of macroeconomics. Remember, what defined the Dark Ages wasn’t the fact that they were primitive — the Bronze Age was primitive, too. What made the Dark Ages dark was the fact that so much knowledge had been lost, that so much known to the Greeks and Romans had been forgotten by the barbarian kingdoms that followed.—Paul Krugman
On peut commencer par l'affirmation de Mark qui explique que Canonical dirige le monde de GNU/Linux vers le mobile, je cite :
I think we are leading the GNU/Linux world into a very important arena, which is mobile personal computing
Tu sais, le plus important n'est pas tellement qu'il y en a déjà avant lui et déjà après lui des distributions gnu/linux portées sur le mobile.
En tant qu'ex-développeur mobile, ce qui me parait évident, c'est que tout ces efforts vont débaucher au mieux sur un succès… d'estime. En tous cas je parie sur un échec commercial.
C'est pas un problème pour les gens qui font ça par passion, mais si j'avais un business comme Shuttleworth (j'ai un mois de revenu d'avance seulement, mais imaginons), je me focaliserais sur résoudre enfin le bug #1 qui a été résolu lui selon lui, mais en tout cas pas par les distributions GNU/Linux.
J'en dis pas plus sinon on va me reprocher de parler pour rien dire.
Ah excellent ! J'adore quand on me démontre que mon opinion du moment est incorrecte :)
Par contre, il n'y a pas encore les fonctionnalités secondaires mais extrêmement pratiques que j'évoquais plus haut, github est down right now, et je n'ai pas le courage de traduire ma prose. Donc si quelqu'un pense que ça a un intérêt d'envoyer des suggestions basées sur elle, il est chaleureusement invité à le faire.
Alors là merci, tu documentes le petit secret que j'ai la flemme de documenter depuis que j'ai découvert ça il y a quelques semaines.
Tu m'ôtes les mots de la bouche
Lorsqu'on est développeur, on a souvent besoin d'avoir accès à de la documentation. Mais par contre, cela nécessite d'avoir un navigateur, de changer d'outil, souvent quitter son éditeur de texte. Et la recherche n'est pas toujours facile, pratique. Dash est une application (pour mac uniquement malheureusement) qui regroupe en un même endroit de très nombreuses documentations de programmation. Et elle se lie à différents éditeurs, ou même permet de réaliser une recherche basée sur la sélection courante, depuis un raccourcis clavier, ce qui permet de ne pas quitter son éditeur pour chercher la documentation. Plutôt pratique, je ne sais pas si des équivalents existent sous linux, mais si ce n'est pas le cas ça serait une bonne idée je pense.
Je m'étais contenté d'écrire un petit mail à mon ancienne boite, où 2 religions (les pro-Apple et les anti-Apple) coexistaient de manière rigolote, en écrivant ceci.
Pour rajouter de l'huile de le feu dans cette guère de religions, voici une petite application géniale et modeste nommée Dash.app (pour mac donc) qui devrait à mon avis réjouir les pro-Apple (en plus de leur être immensément utile) et rendre jaloux les anti-Apple (même si bien évidemment, on ne leur en voudra pas s'ils ne l'avouent pas explicitement. On ferait évidemment pareil à leur place :D )
Blague à part, Dash c'est exactement le genre de design que j'apprécie, à savoir quelqu'un qui s'est penché avec attention sur les réels problèmes qu'ont les gens (les développeurs en l'occurence). Par conséquent, extrêmement pratique.
Allons plus loin dans la publicité gratuite
Snippet manager (Don't Repeat Yourself)
L'utilité de la fonction "accès trivial à la documentation là où on en a besoin quand on en a besoin" est évidente.
Pour les programmeurs évidemment. C'est clair que ça fait gagner du temps de taper singleton`
plutôt que le boilerplate stupide qu'on est obligé de répéter à chaque fois.
Mais même pour les non-développeurs, puisqu'il est tout à fait raisonnable quand on écrit beaucoup de mails de taper politesse`
plutôt que de taper à chaque fois Je vous prie d'agréer, __Name__, l'expression de ma considération distinguée.
Réduire le nombre d'onglets
Avec un peu de chances, je vais bientôt terminer un article où entre autres je suggère de se limiter à maximum 15 onglets (et en général nettement moins).
Bon, c'est quoi le secret quand on est habitués à surfer sur plein d'onglets à la fois pour perdre cette mauvaise habitude ?
Et bien entre autres Dash : très souvent, vous avez autant d'onglets ouverts uniquement parce que l'information dont vous avez besoin est dispersée dans plein de pages. Donc mieux vous résoudre le problème à la source : créer une note correspondant au mini-projet que vous êtes en train de faire, extraire la substantifique moelle de chacun des onglets, les fermer. Goodby insanity.
Ceci nécessite d'avoir une application légère et toujours ouverte, donc moi j'utilise Dash pour ça.
Défauts connus de Dash :
il faudrait que les notes qu'on crée dans Dash soient au format Markdown par défaut, ça serait beaucoup plus pratique.
Il faut que je m'occupe de remonter cette suggestion au développeur, très sympa puisu'il m'a filé les sources d'un de ses autres projets qu'il avait abandonné alors qu'on pouvait en faire quelque-chose de très bien, avec autorisation de faire ce que je veux avec. (un projet de plus à lancer…)
personne ne s'est occupé pour l'instant à ma connaissance de faire aussi bien en libre et sur d'autres plate-formes
Pour ce qui est du fond : Tu fois une dispersion, je vois une richesse.
Pour préciser, le gâchis incroyable d'efforts et de talents n'est pas selon moi, uniquement du fait qu'il y autant de distributions alors que RedHat (pour les grosses boites) et des configurations spécialisées de Debian travaillant en lien étroit avec l'upstream suffiraient pour l'essentiel des besoins (libre évidemment ensuite à chacun de faire son truc à base de Linux From Scratch).
Non, la déperdition d'efforts et de talents est aussi à l'intérieur de chaque distribution.
Et bien ces deux killers-distros du monde GNU/Linux essayent de tout faire et forcément le font mal.
Combien de projets abscons réinventant les briques techniques sous Ubuntu ?
Combien de bureaux sous Mint ?
Est-ce vraiment cela qu'on attend en priorité d'elles ?
Du coup, 22 ans tout juste après le lancement du noyau linux, la seule distribution Linux qui répond aux besoins des gens normaux (hors embarqué. Android, Tom tom et tout ça marchent impec)
la seule distribution Linux qui selon moi a focalisé ses efforts là où c'est réellement important, c'est …
Entre "basculer sur du Full Redmond" et l'image ci-dessous montrant la dispersion des efforts incroyables pointées du doigt par le précédent commentateur, n'y aurait-il pas hasard un juste milieu ?
Ah merci !
Pour la prochaine fois, je vais essayé mais c'est pas gagné.
Pas impossible non plus car le sort opposé de mes deux journaux (le premier à-30 le second à +50) montre que le linuxfrien est parfois vache (je me suis retrouvé pas mal bloqué dans tous les sens mais pas rancunier (je me suis plus appliqué pour le second certes… Passer de - 30 à +50 m'a néanmoins surpris)
Hello, merci de l'information qui me sera utile pour ce projet particulier
Mais ça n'enlève rien à la question que je soulevais qu est celle ci :
Plein de gens ont de bonnes idées, utiles
Plein de gens ont des compétences et du temps pour réaliser quelque chose de bien
Mais c'est en général pas les mêmes personnes ou pas les bonnes compétences ou pas au bon moment
Il faudrait donc un site (anglophone) pour qu'ils puissent se rencontrer
Ca serait similaire à du Crowdfunding, sauf qu'on apporterait ses petites compétences au lieu de petites sommes monétaires
Si ça existe déjà, pourquoi ce n'est pas plus connu ?
Si ça n'existe pas, il faut le créer non ?
Diable, excuse moi d'être aussi bête et de ne parler pour rien.
J'expliquerais peut-être un jour pourquoi je pense qu'il vaut mieux que l'ordinateur s'acharne à comprendre l'humain que l'inverse, mais pour l'instant apparemment c'est impossible.
Oui c'est une possibilité à laquelle j'avais pensé et que je n'exclus pas du tout bien sûr.
Mais il me semble
- que les linuxfriens préfèrent voir d'autres choses, plus orienté détente, dans les journaux (ce qui n'est pas un problème),
- surtout que, si jamais le projet prenait de l'ampleur, il ferait un jour ou l'autre expliquer le projet en anglais, et dans cas là, s'il y a un endroit plus adapté, pourquoi ne pas le faire directement si en plus ça permet de toucher plus de développeurs potentiels ?
Le livre parle de Javascript pas de JSON… Tu es au courant que les grammaires n'ont rien à voir ? (double quote obligatoire par exemple).
Ben oui je suis au courant… depuis précisément que j'ai lu LE livre qui montrait que Javascript n'était pas le langage pourri que tout le monde dénonçait, qu'il avait des "good parts", et qui en même temps inventait ce standard qu'est le JSON à partir des objets en javascript.
Donc Douglas Crockford parle à la fois de Javascript et de JSON dans ce livre.
Parse error on line 2:
{ "foo": "bar"//comment}
Exactement le problème : Douglas Crockford qui est un type brillant, sinon il n'aurait pas inventé JSlint pour aider les gens médiocrement intelligents comme moi, n'est pas allé totalement au bout de sa démarche, puisque voilà ce qu'il aurait pu faire.
Parse error on line 2: Comments are not allowed [Details]
{ "foo": "bar"//comment}
Et quand on cliquerait sur [Details], on verrait
Coments are not allowed in JSON since that would destroy interoperability
It can still makes sense to keep comments in a josn file and use a took like jsonmanify to output it minified and without the comments
See http://json.org/json-and-comments-FAKEURL for details
Et bien sûr, ce n'est pas le standard qui doit faire les parseurs, mais c'est lui qui peut expliquer aux gens qui vont faire les parseurs pourquoi il est important de le faire.
J'ai l'impression que les gens qui m'ont noté à -8, (en soit je m'en fous), l'on fait, outre cette histoire de premier degré qui passe mal à l'écrit, parce qu'ils ont cru que j'attaquais JSON.
Non, disons le au premier degré : JSON est un truc extrêmement utile et beaucoup mieux pensé que cette absurdité de XML et de l'écosystème toujours plus absurde qui s'est accumulé autour de lui. C'est juste que faire comprendre la psychologie humaine à des programmes informatiques est incroyablement difficile.
Plutot que de la psychologie, fais plutot ton boulot en lisant le standard qui ne fait même pas 5 pages.
Si c'était juste que j'avais pas fait mon boulot, je confesserais ma faute, et le problème serait réglé.
Mais pour aggraver mon cas, je vais confesser avoir lu, bien avant de perdre une masse considérable de temps et d'énergie sur cette histoire de commentaires insérés dans les objets javascript mais pas dans le json, le fabuleux libre JavaScript, The Good Parts de Douglas Crockford, qui, entre autres explications lumineuse, expose tout l'intérêt du JSON, son invention.
Et le livre fait 172 pages, pas 5.
Donc tu vois, ce n'est pas que je n'ai pas fait mon boulot, c'est juste que je suis Humain, trop humain
Maintenant si tu connais stackoverflow, tu retournes voir la page que je citais où quelqu'un demande si les commentaires sont autorisés dans le json, et si oui comment, et tu verras qu'il y a une anomalie là dessus. Stackoverflow étant d'une efficacité extrême, (parce que justement ses concepteurs ont beaucoup pensé à cette histoire de psychologie humaine), les questions simples ont des réponses simples bien plus rapidement que ça.
J'ai regardé la spec, et ils ont pas prévu le truc absolument indispensable[1] à prendre en compte, donc j'ai bien peur que ce soit encore un standard pour rien, utilisé par pas grand monde.
[1] vu que c'est moi qui l'ait pointé du doigt, voir aussi 4 commentaires auparavant dans le thread où j'expliquais que mon incapacité à comprendre la psychologie des programmes informatiques m'avait fait passé >3h sur ce truc
PS: Ah mince, on me dit dans l'oreillette que c'est un truc déjà pas mal utilisé
PPS: excellent titre de journal, vraiment :-)
(puisque la précision précise que ça ne marche que sur Firefox et Safari pour l'instant).
Euh … j'ai testé sous IE8, Chromium, Firefox, Konqueror, et les animations marchent chez moi. Est-ce que tu pourrais donner plus d'info sur le problème que tu as ?
Euh… en fait aucun pour l'instant puisque je n'ai pas encore pris le temps de le tester
J'avais en fait tout simplement fait confiance à la présentation datant de Juin 2013 où vous confessiez que votre produit n'était pas au point (fausse modestie quand tu nous tient ;-)
Some improvements we have thought about :
2. a stronger multi-navigator support for the viewer (at the moment, only Firefox and Safari are supported)
Mais imaginons que je veuille voir si avec mes maigres connaissances je peux aider à améliorer l'affichage du screencast Dahu sur Google Chrome (puisque la précision précise que ça ne marche que sur Firefox et Safari pour l'instant).
Comment fais-je concrètement ? C'est un peu obscur pour l'instant.
oui mais le jeu c'est pas tellement de savoir qui peut remonter le plus d'erreurs possibles et que la syntaxe soit peu ambigüe pour le compilateur
il faut surtout que les erreurs qu'ils remontent soient claires et la syntaxe peu surprenantes pour le bipède
et puis il faut que tout l'éco-système derrière comprenne ça;
Par exemple là grâce à stackoverflow, j'ai fini par comprendre ce qui se passait
Le truc intolérable pour l'ordinateur que j'avais fait, c'était, rendez-vous compte, de mettre des commentaires dans un json.
Bon json, je savais grosso-modo que c'était des objets javascripts avec quelques restrictions de bon sens pour que ça s'échange mieux avec les autres langages (j'avais lu JavaScript, The Good Parts) mais ça m'était sorti de l'esprit que les commentaires c'était hors de question… vu que dans mon cas c'était à mon avis pertinent.
Oui mais effectivement, le designer de json, moins bête ou du moins instruit par la bêtise de ceux qui ont conçu xml, avait réfléchi à ça :
Comments were removed from JSON by design.
"I removed comments from JSON because I saw people were using them to hold parsing directives, a practice which would have destroyed interoperability. I know that the lack of comments makes some people sad, but it shouldn't."
Suppose you are using JSON to keep configuration files, which you would like to annotate. Go ahead and insert all the comments you like. Then pipe it through JSMin before handing it to your JSON parser.
En y réfléchissant, il avait raison de faire ça.
Autoriser les commentaires aurait été pire que de les interdire.
N'empêche que j'ai perdu énormément de temps sur ce problème ridicule
Et pas que moi, il suffit de voir le score considérable de la question sur stackoverflow, et le nombre de réponses ayant un score élevé
QUESTION : Score 895 : Can I comment a JSON file? If so, how?
Score 515: I don't believe you can have an actual comment. (…)
Score 216: No, comments in JSON are not allowed, see RFC et json.org (..)
Score 126 : It's not allowed because people would do bad things, but it useful if you know what you do. So I just released JSON.minify() which strips out comments and whitespace from a block of JSON and makes it valid JSON that can be parsed. (…) See my very long blog post here http://blog.getify.com/json-comments/
Score 70: I've found a little hack that allows you to place comments in a JSON file that will not affect the parsing, or alter the data being represented in any way.
Score 50 : Comments were removed from JSON by design. (j'en parle au-dessus)
Et d'autres encore.
En tout cas ça montre qu'il y a un réel problème d'utilisabilité là…
Auquel pourtant le designer avait très bien pensé, mais pas jusqu'au bout…
Qu'est-ce qu'il aurait du faire de plus en fait ?
Une page ad-hoc sur le site officiel de json expliquant pourquoi envoyer des données via json serait une idée horrible
Un paragraphe indiquant qu'un truc comme jsonminify par contre serait bienvenu et qu'il peut lister sur une page à part les logiciels bien fait qui font ça
Une note à l'intention des gens qui font les parseurs de json pour leur dire que interdire les commentaires, qui sont naturels quand on connait le javascript, va surprendre un tas de gens qui utilisent json sans connaitre tous les tenants aboutissant. Et donc, qu'il faut qu'ils fassent un message d'erreur explicite renvoyant vers la page de son site
Bref, beaucoup de tremblement d'ailes de papillons qui évitent qu'un tremblement de terre ne se déclenche à tout instant à des centaines de kilomètres de là.
D'où ma question : pour penser à tous ces petits détails extrèmement importants, ne vaut-il pas mieux commencer sur une base minimaliste comme Go l'a fait, quitte à rajouter ensuite les choses qui manquent vraiment ?
Mais à mon avis, on aura beau prendre les meilleures plumes connaissant l'informatique de la planète, leur demandant d'améliorer les messages d'erreur d'un compilateur C++ existant (pas gcc ce serait trop difficile, llvm), on fera des progrès, mais on sera très loin du compte. On pourra refaire un compilateur C++ en voyant ça comme un des trois objectifs prioritaires, on fera encore plus de progrès, mais on sera encore loin du compte vu la complexité de C++. Après Go ? Je ne sais pas si Go est à peu près à la hauteur de la tâche, mais au moins il est clair que d'un point de vue design, c'était quelque chose de prioritaire dès le début.
Ce qui est primordial car le design (tolérance aux erreurs d'humains qui ne connaissent pas à fond leur langage, leur environenment de programmation, …) ça peut pas être un truc rajouté après coup.
[^] # Re: Mark a besoin d'un business rentable, c'est légitime, et cela explique son discours
Posté par jean-michel.bertrou.eu . En réponse au journal L'open source Tea party et Mark Shuttleworth. Évalué à 2.
Merci de ces références.
Mais pas d'accord sur ta conclusion : que ça a été un peu tenté ne prouve pas que ça ne marchera jamais.
Je ne vois pas comment ça pourrait le prouver étant donné que Chrome OS (basé sur Linux) et Firefox OS (basé sur Linux) ont tenté ça vraiment et ont réussi pour l'un et va réussir pour l'autre.
Non, le problème c'est que ça a été seulement un peu tenté
Ca n'a jamais été une des 3 priorités essentielles ni de Cannical, ni des autres, eeePC excepté—et encore même eux, on se demande s'ils ont vraiment essayé de faire les choses très très bien… ou s'ils sont seulement servi de GNU/Linux de le temps de montrer que leur concept d'ordinateur d marchait et d'obtenir une grosse ristourne pour Windows XP
En tous cas , moi je pars du principe qu'il faut s'inspirer de ce qu'il se fait de mieux, donc pas de telle distribtuion qui a lancé un modèle avec tel supermarché ; non : s'inspirer de ce qu'a fait Google pour Chrome OS et Mozilla pour Firefox OS
[^] # Re: Réponse lapidaire : Ubuntu mobile ne peut aller que dans le mur
Posté par jean-michel.bertrou.eu . En réponse au journal L'open source Tea party et Mark Shuttleworth. Évalué à -1.
oui, on pourrait appeler ça Chrome OS ou Firefox OS par exemple
je donne le lien vers l'article brillant de Tristan Nitot : http://standblog.org/blog/post/2004/07/14/93113583-le-navigateur-en-tant-que-plate-forme
2004 : moi je trouve ça incroyablement visionnaire
surtout que c'est pas juste qu'il a deviné que ça allait arrivé, lui et plein d'autres ont fait plein d'efforts dans ce sens
[^] # Re: Réponse lapidaire : Ubuntu mobile ne peut aller que dans le mur
Posté par jean-michel.bertrou.eu . En réponse au journal L'open source Tea party et Mark Shuttleworth. Évalué à -3.
Mieux vaut tard que jamais :)
Cherche dans les archives du blog de Tristan Nitot, il a compris ça depuis très longtemps, et c'est lui qui me l'a fait comprendre.
[^] # Re: Mark a besoin d'un business rentable, c'est légitime, et cela explique son discours
Posté par jean-michel.bertrou.eu . En réponse au journal L'open source Tea party et Mark Shuttleworth. Évalué à 1. Dernière modification le 19 octobre 2013 à 21:19.
Je suis d'accord avec toi : c'est une condition nécessaire et non suffisante pour sortir de l'impasse actuelle. Il aurait fallu faire depuis longtemps d'ailleurs (mais bon, on ne peut pas changer le passé). Chrome OS et Firefox OS ont pensé à ça dès le départ, le premier marche très bien et le second, je pense qu'il va très bien marcher aussi. (D'ailleurs je viens de ramener un smartphone Firefox OS de Colombie)
Alors que GNU/linux… ça fait (malheureusement) longtemps que ça m'inspire cette citation d'Albert Einstein :
Insanity: doing the same thing over and over again and expecting different results.
[^] # Re: Mark a besoin d'un business rentable, c'est légitime, et cela explique son discours
Posté par jean-michel.bertrou.eu . En réponse au journal L'open source Tea party et Mark Shuttleworth. Évalué à 2. Dernière modification le 19 octobre 2013 à 18:25.
Laisser tomber le mobile (voir plus haut), se focaliser sur ce qu'il avait prévu de faire au début, c'est à dire une distribution Linux que les gens normaux peuvent et ont envie utiliser sans se prendre la tête. Pour cela, travailler main dans la main avec Debian, et se concentrer sur ce qui est important pour les utilisateurs, ce qui est très rarement la même chose que les projets excitants techniquement.
Oui c'est pas gagné, mais comme tu poses la question, je te donne mon avis ;)
[^] # Re: Réponse lapidaire : Ubuntu mobile ne peut aller que dans le mur
Posté par jean-michel.bertrou.eu . En réponse au journal L'open source Tea party et Mark Shuttleworth. Évalué à -2. Dernière modification le 19 octobre 2013 à 18:18.
J'envisageais les choses d'un autre point de vue, mais tu as parfaitement raison là dessus.
Ceci dit, pour moi qui ait un peu envie de démontrer aux incompétents qui trustent les postes de gens sérieux dans l'informatique en France, un succès d'estime ne me suffirait pas ; donc personnellement, si je restais spécialisé dans le mobile, je focaliserais mon énergie et mes maigres talents sur Firefox OS, parce que ça oui, j'y crois beaucoup.
Raison simple : le WEB est le seul système d'exploitation qui a une chance sérieuse de concurrencer iOS (qui va rester important mais décliner) et surtout Android.
C'est la réflexion que je me suis faite après avoir lu cet éditorial[1] de l'étonnant Paul Krugman, qui après avoir été une épine constante[2] de le pied George W Bush, après avoir dénoncé ses confrères économistes "we are in the middle-age of macro-économy"[2] montre en peu de mots à son habitude qu'il a tout compris de l'informatique[1]
# Réponse lapidaire : Ubuntu mobile ne peut aller que dans le mur
Posté par jean-michel.bertrou.eu . En réponse au journal L'open source Tea party et Mark Shuttleworth. Évalué à 1.
Tu sais, le plus important n'est pas tellement qu'il y en a déjà avant lui et déjà après lui des distributions gnu/linux portées sur le mobile.
En tant qu'ex-développeur mobile, ce qui me parait évident, c'est que tout ces efforts vont débaucher au mieux sur un succès… d'estime. En tous cas je parie sur un échec commercial.
C'est pas un problème pour les gens qui font ça par passion, mais si j'avais un business comme Shuttleworth (j'ai un mois de revenu d'avance seulement, mais imaginons), je me focaliserais sur résoudre enfin le bug #1 qui a été résolu lui selon lui, mais en tout cas pas par les distributions GNU/Linux.
J'en dis pas plus sinon on va me reprocher de parler pour rien dire.
[^] # Re: Equivalent de Dash pour Linux
Posté par jean-michel.bertrou.eu . En réponse au journal De tout, de rien, des bookmarks, du bla bla 42. Évalué à -5.
Ah excellent ! J'adore quand on me démontre que mon opinion du moment est incorrecte :)
Par contre, il n'y a pas encore les fonctionnalités secondaires mais extrêmement pratiques que j'évoquais plus haut, github est down right now, et je n'ai pas le courage de traduire ma prose. Donc si quelqu'un pense que ça a un intérêt d'envoyer des suggestions basées sur elle, il est chaleureusement invité à le faire.
# Dash, mais oui !
Posté par jean-michel.bertrou.eu . En réponse au journal De tout, de rien, des bookmarks, du bla bla 42. Évalué à 2. Dernière modification le 18 octobre 2013 à 21:33.
Alors là merci, tu documentes le petit secret que j'ai la flemme de documenter depuis que j'ai découvert ça il y a quelques semaines.
Tu m'ôtes les mots de la bouche
Je m'étais contenté d'écrire un petit mail à mon ancienne boite, où 2 religions (les pro-Apple et les anti-Apple) coexistaient de manière rigolote, en écrivant ceci.
Pour rajouter de l'huile de le feu dans cette guère de religions, voici une petite application géniale et modeste nommée Dash.app (pour mac donc) qui devrait à mon avis réjouir les pro-Apple (en plus de leur être immensément utile) et rendre jaloux les anti-Apple (même si bien évidemment, on ne leur en voudra pas s'ils ne l'avouent pas explicitement. On ferait évidemment pareil à leur place :D )
Blague à part, Dash c'est exactement le genre de design que j'apprécie, à savoir quelqu'un qui s'est penché avec attention sur les réels problèmes qu'ont les gens (les développeurs en l'occurence). Par conséquent, extrêmement pratique.
Allons plus loin dans la publicité gratuite
Snippet manager (Don't Repeat Yourself)
L'utilité de la fonction "accès trivial à la documentation là où on en a besoin quand on en a besoin" est évidente.
Sauf que Dash est aussi, et c'est moins évident, un snippets manager très pratique.
Pour les programmeurs évidemment. C'est clair que ça fait gagner du temps de taper
singleton`
plutôt que le boilerplate stupide qu'on est obligé de répéter à chaque fois.
Mais même pour les non-développeurs, puisqu'il est tout à fait raisonnable quand on écrit beaucoup de mails de taper
politesse`
plutôt que de taper à chaque fois
Je vous prie d'agréer, __Name__, l'expression de ma considération distinguée.Réduire le nombre d'onglets
Avec un peu de chances, je vais bientôt terminer un article où entre autres je suggère de se limiter à maximum 15 onglets (et en général nettement moins).
Bon, c'est quoi le secret quand on est habitués à surfer sur plein d'onglets à la fois pour perdre cette mauvaise habitude ?
Et bien entre autres Dash : très souvent, vous avez autant d'onglets ouverts uniquement parce que l'information dont vous avez besoin est dispersée dans plein de pages. Donc mieux vous résoudre le problème à la source : créer une note correspondant au mini-projet que vous êtes en train de faire, extraire la substantifique moelle de chacun des onglets, les fermer. Goodby insanity.
Ceci nécessite d'avoir une application légère et toujours ouverte, donc moi j'utilise Dash pour ça.
Défauts connus de Dash :
Il faut que je m'occupe de remonter cette suggestion au développeur, très sympa puisu'il m'a filé les sources d'un de ses autres projets qu'il avait abandonné alors qu'on pouvait en faire quelque-chose de très bien, avec autorisation de faire ce que je veux avec. (un projet de plus à lancer…)
[^] # Il manque un GPS pour ne pas tourner en rond (Was: Une N-ième distrib ..)
Posté par jean-michel.bertrou.eu . En réponse au journal Une distribution argentine : Huayra. Évalué à -1. Dernière modification le 17 octobre 2013 à 20:06.
Pour préciser, le gâchis incroyable d'efforts et de talents n'est pas selon moi, uniquement du fait qu'il y autant de distributions alors que RedHat (pour les grosses boites) et des configurations spécialisées de Debian travaillant en lien étroit avec l'upstream suffiraient pour l'essentiel des besoins (libre évidemment ensuite à chacun de faire son truc à base de Linux From Scratch).
Non, la déperdition d'efforts et de talents est aussi à l'intérieur de chaque distribution.
Parlons uniquement d'Ubuntu et Mint puisque ce sont les killer-distros du moment
http://distrowatch.com/dwres.php?resource=popularity
Et bien ces deux killers-distros du monde GNU/Linux essayent de tout faire et forcément le font mal.
Combien de projets abscons réinventant les briques techniques sous Ubuntu ?
Combien de bureaux sous Mint ?
Est-ce vraiment cela qu'on attend en priorité d'elles ?
Du coup, 22 ans tout juste après le lancement du noyau linux, la seule distribution Linux qui répond aux besoins des gens normaux (hors embarqué. Android, Tom tom et tout ça marchent impec)
la seule distribution Linux qui selon moi a focalisé ses efforts là où c'est réellement important, c'est …
http://en.wikipedia.org/wiki/Chrome_OS
Libre à toi de ne pas être d'accord avec moi.
En attendant, je trouve ça énormément dommage.
Le logiciel libre est un bazar d'une richesse incroyable qui avance très vite… mais il lui manque un GPS pour ne pas tourner en rond
[^] # Re: Une N-ième distrib ..
Posté par jean-michel.bertrou.eu . En réponse au journal Une distribution argentine : Huayra. Évalué à 3.
Raisonnement fallacieux détecté !
Entre "basculer sur du Full Redmond" et l'image ci-dessous montrant la dispersion des efforts incroyables pointées du doigt par le précédent commentateur, n'y aurait-il pas hasard un juste milieu ?
[^] # Re: Encore un standard que personne utilisera
Posté par jean-michel.bertrou.eu . En réponse au journal JSON : Data Interchange Format not found.... Évalué à 0.
Ah merci !
Pour la prochaine fois, je vais essayé mais c'est pas gagné.
Pas impossible non plus car le sort opposé de mes deux journaux (le premier à-30 le second à +50) montre que le linuxfrien est parfois vache (je me suis retrouvé pas mal bloqué dans tous les sens mais pas rancunier (je me suis plus appliqué pour le second certes… Passer de - 30 à +50 m'a néanmoins surpris)
[^] # Crowdfunding où chacun apporte ses petites compétences
Posté par jean-michel.bertrou.eu . En réponse au message Où apporter des idées de projets libres aux développeurs en recherche de bonnes idées ?. Évalué à 1.
Hello, merci de l'information qui me sera utile pour ce projet particulier
Mais ça n'enlève rien à la question que je soulevais qu est celle ci :
Plein de gens ont de bonnes idées, utiles
Plein de gens ont des compétences et du temps pour réaliser quelque chose de bien
Mais c'est en général pas les mêmes personnes ou pas les bonnes compétences ou pas au bon moment
Il faudrait donc un site (anglophone) pour qu'ils puissent se rencontrer
Ca serait similaire à du Crowdfunding, sauf qu'on apporterait ses petites compétences au lieu de petites sommes monétaires
Si ça existe déjà, pourquoi ce n'est pas plus connu ?
Si ça n'existe pas, il faut le créer non ?
[^] # Re: Encore un standard que personne utilisera
Posté par jean-michel.bertrou.eu . En réponse au journal JSON : Data Interchange Format not found.... Évalué à -9.
Diable, excuse moi d'être aussi bête et de ne parler pour rien.
J'expliquerais peut-être un jour pourquoi je pense qu'il vaut mieux que l'ordinateur s'acharne à comprendre l'humain que l'inverse, mais pour l'instant apparemment c'est impossible.
[^] # Re: Journal
Posté par jean-michel.bertrou.eu . En réponse au message Où apporter des idées de projets libres aux développeurs en recherche de bonnes idées ?. Évalué à 1.
ça va être dur ça, mais promis, je vais essayer ;-)
[^] # Re: Journal
Posté par jean-michel.bertrou.eu . En réponse au message Où apporter des idées de projets libres aux développeurs en recherche de bonnes idées ?. Évalué à 1.
Oui c'est une possibilité à laquelle j'avais pensé et que je n'exclus pas du tout bien sûr.
Mais il me semble
- que les linuxfriens préfèrent voir d'autres choses, plus orienté détente, dans les journaux (ce qui n'est pas un problème),
- surtout que, si jamais le projet prenait de l'ampleur, il ferait un jour ou l'autre expliquer le projet en anglais, et dans cas là, s'il y a un endroit plus adapté, pourquoi ne pas le faire directement si en plus ça permet de toucher plus de développeurs potentiels ?
[^] # Re: Encore un standard que personne utilisera
Posté par jean-michel.bertrou.eu . En réponse au journal JSON : Data Interchange Format not found.... Évalué à -4. Dernière modification le 15 octobre 2013 à 11:15.
Ben oui je suis au courant… depuis précisément que j'ai lu LE livre qui montrait que Javascript n'était pas le langage pourri que tout le monde dénonçait, qu'il avait des "good parts", et qui en même temps inventait ce standard qu'est le JSON à partir des objets en javascript.
Donc Douglas Crockford parle à la fois de Javascript et de JSON dans ce livre.
Exactement le problème : Douglas Crockford qui est un type brillant, sinon il n'aurait pas inventé JSlint pour aider les gens médiocrement intelligents comme moi, n'est pas allé totalement au bout de sa démarche, puisque voilà ce qu'il aurait pu faire.
Et quand on cliquerait sur [Details], on verrait
Et bien sûr, ce n'est pas le standard qui doit faire les parseurs, mais c'est lui qui peut expliquer aux gens qui vont faire les parseurs pourquoi il est important de le faire.
J'ai l'impression que les gens qui m'ont noté à -8, (en soit je m'en fous), l'on fait, outre cette histoire de premier degré qui passe mal à l'écrit, parce qu'ils ont cru que j'attaquais JSON.
Non, disons le au premier degré : JSON est un truc extrêmement utile et beaucoup mieux pensé que cette absurdité de XML et de l'écosystème toujours plus absurde qui s'est accumulé autour de lui. C'est juste que faire comprendre la psychologie humaine à des programmes informatiques est incroyablement difficile.
[^] # Re: Encore un standard que personne utilisera
Posté par jean-michel.bertrou.eu . En réponse au journal JSON : Data Interchange Format not found.... Évalué à -2. Dernière modification le 15 octobre 2013 à 10:19.
Si c'était juste que j'avais pas fait mon boulot, je confesserais ma faute, et le problème serait réglé.
Mais pour aggraver mon cas, je vais confesser avoir lu, bien avant de perdre une masse considérable de temps et d'énergie sur cette histoire de commentaires insérés dans les objets javascript mais pas dans le json, le fabuleux libre JavaScript, The Good Parts de Douglas Crockford, qui, entre autres explications lumineuse, expose tout l'intérêt du JSON, son invention.
Et le livre fait 172 pages, pas 5.
Donc tu vois, ce n'est pas que je n'ai pas fait mon boulot, c'est juste que je suis Humain, trop humain
Maintenant si tu connais stackoverflow, tu retournes voir la page que je citais où quelqu'un demande si les commentaires sont autorisés dans le json, et si oui comment, et tu verras qu'il y a une anomalie là dessus. Stackoverflow étant d'une efficacité extrême, (parce que justement ses concepteurs ont beaucoup pensé à cette histoire de psychologie humaine), les questions simples ont des réponses simples bien plus rapidement que ça.
[^] # Re: Encore un standard que personne utilisera
Posté par jean-michel.bertrou.eu . En réponse au journal JSON : Data Interchange Format not found.... Évalué à 1. Dernière modification le 15 octobre 2013 à 09:32.
Ouh là… comment dire… on va dire que le second degré passe mal à l'écrit.
# Encore un standard que personne utilisera
Posté par jean-michel.bertrou.eu . En réponse au journal JSON : Data Interchange Format not found.... Évalué à -6. Dernière modification le 15 octobre 2013 à 00:18.
J'ai regardé la spec, et ils ont pas prévu le truc absolument indispensable[1] à prendre en compte, donc j'ai bien peur que ce soit encore un standard pour rien, utilisé par pas grand monde.
[1] vu que c'est moi qui l'ait pointé du doigt, voir aussi 4 commentaires auparavant dans le thread où j'expliquais que mon incapacité à comprendre la psychologie des programmes informatiques m'avait fait passé >3h sur ce truc
PS: Ah mince, on me dit dans l'oreillette que c'est un truc déjà pas mal utilisé
PPS: excellent titre de journal, vraiment :-)
[^] # Re: RTFM howto ?
Posté par jean-michel.bertrou.eu . En réponse au journal Dahu : faire des présentations à base de screenshots (a la Wink). Évalué à 1.
Merci pour les précisions !
Euh… en fait aucun pour l'instant puisque je n'ai pas encore pris le temps de le tester
J'avais en fait tout simplement fait confiance à la présentation datant de Juin 2013 où vous confessiez que votre produit n'était pas au point (fausse modestie quand tu nous tient ;-)
Some improvements we have thought about :
2. a stronger multi-navigator support for the viewer (at the moment, only Firefox and Safari are supported)
http://dahuapp.github.io/presentation/dahuproject.html#slide-12
PS corporatiste : c'est une impression ou il y a pas mal de choses bien conçues et/ou réalisées par des gens qui ont fait l'ENSIMAG ?[^] # RTFM howto ?
Posté par jean-michel.bertrou.eu . En réponse au journal Dahu : faire des présentations à base de screenshots (a la Wink). Évalué à 2.
En revanche, je ne vois pas trop comment on fait pour Read The Fine Documentation ?
Il y a 6 repositories sur https://github.com/dahuapp et c'est bien
Mais imaginons que je veuille voir si avec mes maigres connaissances je peux aider à améliorer l'affichage du screencast Dahu sur Google Chrome (puisque la précision précise que ça ne marche que sur Firefox et Safari pour l'instant).
Comment fais-je concrètement ? C'est un peu obscur pour l'instant.
[^] # Re: Superbe
Posté par jean-michel.bertrou.eu . En réponse au journal Dahu : faire des présentations à base de screenshots (a la Wink). Évalué à 2.
je dirais même plus… limite génial.
Il suffisait d'y penser comme dirait l'autre :-)
[^] # Re: Go vs C++ (et Rust ?) : Minimalisme versus sophistication
Posté par jean-michel.bertrou.eu . En réponse à la dépêche Présentation de Rust 0.8. Évalué à 0. Dernière modification le 13 octobre 2013 à 14:05.
oui mais le jeu c'est pas tellement de savoir qui peut remonter le plus d'erreurs possibles et que la syntaxe soit peu ambigüe pour le compilateur
il faut surtout que les erreurs qu'ils remontent soient claires et la syntaxe peu surprenantes pour le bipède
et puis il faut que tout l'éco-système derrière comprenne ça;
Par exemple là grâce à stackoverflow, j'ai fini par comprendre ce qui se passait
Le truc intolérable pour l'ordinateur que j'avais fait, c'était, rendez-vous compte, de mettre des commentaires dans un json.
Bon json, je savais grosso-modo que c'était des objets javascripts avec quelques restrictions de bon sens pour que ça s'échange mieux avec les autres langages (j'avais lu JavaScript, The Good Parts) mais ça m'était sorti de l'esprit que les commentaires c'était hors de question… vu que dans mon cas c'était à mon avis pertinent.
Oui mais effectivement, le designer de json, moins bête ou du moins instruit par la bêtise de ceux qui ont conçu xml, avait réfléchi à ça :
Comments were removed from JSON by design.
"I removed comments from JSON because I saw people were using them to hold parsing directives, a practice which would have destroyed interoperability. I know that the lack of comments makes some people sad, but it shouldn't."
Suppose you are using JSON to keep configuration files, which you would like to annotate. Go ahead and insert all the comments you like. Then pipe it through JSMin before handing it to your JSON parser.
Public statement by Douglas Crockford on G+
http://stackoverflow.com/questions/244777/can-i-comment-a-json-file
En y réfléchissant, il avait raison de faire ça.
Autoriser les commentaires aurait été pire que de les interdire.
N'empêche que j'ai perdu énormément de temps sur ce problème ridicule
Et pas que moi, il suffit de voir le score considérable de la question sur stackoverflow, et le nombre de réponses ayant un score élevé
QUESTION : Score 895 : Can I comment a JSON file? If so, how?
Score 515: I don't believe you can have an actual comment. (…)
Score 216: No, comments in JSON are not allowed, see RFC et json.org (..)
Score 126 : It's not allowed because people would do bad things, but it useful if you know what you do. So I just released JSON.minify() which strips out comments and whitespace from a block of JSON and makes it valid JSON that can be parsed. (…) See my very long blog post here http://blog.getify.com/json-comments/
Score 70: I've found a little hack that allows you to place comments in a JSON file that will not affect the parsing, or alter the data being represented in any way.
Score 50 : Comments were removed from JSON by design. (j'en parle au-dessus)
Et d'autres encore.
En tout cas ça montre qu'il y a un réel problème d'utilisabilité là…
Auquel pourtant le designer avait très bien pensé, mais pas jusqu'au bout…
Qu'est-ce qu'il aurait du faire de plus en fait ?
Bref, beaucoup de tremblement d'ailes de papillons qui évitent qu'un tremblement de terre ne se déclenche à tout instant à des centaines de kilomètres de là.
D'où ma question : pour penser à tous ces petits détails extrèmement importants, ne vaut-il pas mieux commencer sur une base minimaliste comme Go l'a fait, quitte à rajouter ensuite les choses qui manquent vraiment ?
[^] # Re: Go vs C++ (et Rust ?) : Minimalisme versus sophistication
Posté par jean-michel.bertrou.eu . En réponse à la dépêche Présentation de Rust 0.8. Évalué à 0.
Oui ce serait utile.
Mais à mon avis, on aura beau prendre les meilleures plumes connaissant l'informatique de la planète, leur demandant d'améliorer les messages d'erreur d'un compilateur C++ existant (pas gcc ce serait trop difficile, llvm), on fera des progrès, mais on sera très loin du compte. On pourra refaire un compilateur C++ en voyant ça comme un des trois objectifs prioritaires, on fera encore plus de progrès, mais on sera encore loin du compte vu la complexité de C++. Après Go ? Je ne sais pas si Go est à peu près à la hauteur de la tâche, mais au moins il est clair que d'un point de vue design, c'était quelque chose de prioritaire dès le début.
Ce qui est primordial car le design (tolérance aux erreurs d'humains qui ne connaissent pas à fond leur langage, leur environenment de programmation, …) ça peut pas être un truc rajouté après coup.