Laurent J a écrit 2938 commentaires

Pourquoi ce manque ? Ou c'est moi qui confond des extensions de SpiderMonkey avec le standard ?

Non c'est juste que certaines versions de Node (entre NodeJS v4.0+, la serie NodeJS v0.12 toujours maintenue et Io.js, j'y perd mon latin) utilise une vieille version de V8. La fonction repeat n'est apparu à priori que dans Chrome 41, ce qui correspond à V8 4.1. Or V8 4.1 n'est utilisé que depuis io.js v1.0.3 et donc NodeJS v4.0.0. Donc il y a à peine plus d'un an.

Alors que Spidermonkey l'implémente depuis Firefox 24, c'est à dire septembre 2013.

Par contre tes bidules npm non, c'est à toi de savoir que ça va merder et qu'il faut recompiler.

Il y a des paquets npm qui nécessitent une compilation ?

Oui d'ailleurs, je doute que dans 50 ans on ait autant de voitures de collection datant de ces dix dernières années, que de voitures de collection de maintenant.

Les voitures de collections d'aujourd'hui (qui ont donc 30 ans et +) n'ont quasiment pas d’électronique. Il est "simple" de rénover ces voitures. Il "suffit" de réusiner/refabriquer les pièces manquantes ("simple" et "suffit" pour dire que ce n'est pas impossible, même si ça demande un savoir faire, du travail et du matériel). Quoique pour les pièces plastiques, c'est un peu plus compliqué à reproduire j'imagine (faut des moules, tout ça..)

Par contre, pour refaire une carte électronique comme celles utilisées dans les voitures d'aujourd'hui, avec le microcode et cie des différentes puces (sans parler des ordinateurs du tableau de bord qui pilotent les tablettes embarquées, les GPS et cie), je me demande si ça sera vraiment faisable dans 30 ans quand on n'aura plus la technologie ou les sources ou mêmes des images binaires des systèmes embarqués… Sauf si certains ont déjà pensé à ça, et piratent les ordinateurs embarqués de leur voiture préférés pour en extraire les ROMS afin de pouvoir les réutiliser plus tards (au pire dans des émulateurs), à la manière des ROMS de nos vieilles consoles/vieux ordinateurs des années 80 :-)

Sinon, je ne connais pas la taille exacte de l'équipe de développement, mais mon petit doigt me dit qu'elle n'est probablement pas suffisante pour les "side-projects" voulus :

Comme Linux a sa naissance quoi ;-)

Est-ce que ça veut dire que personne n'a pensé au projet dans son ensemble avant d'aller dans son éditeur de code préféré ?

J'aime bien ta naïveté :-) Depuis quand il y a de la doc sur des projets open-source fraichement démarrés ? ^{_^} (ouai on n'est pas vendredi, je sais).

J'ai comme l'impression que tu n'as pas vécu, voir tu n'étais pas encore né, un certain 5 octobre 1991, sinon tu te serais tout autant plaint ;-)

Sinon je te recommande la lecture des livres de Tanenbaum, peut être que ça aidera à comprendre le fonctionnement de cet OS (ou pas, déjà faudrait comprendre le Rust, que je ne connais pas vraiment).

on peut se poser la question de la fiabilité des projets JavaScript qui dépendent de centaines de modules npm

On peut se poser aussi la question d'utiliser npm tout court, qui est un système de paquet complètement pourri de mon point de vue, où, pour un même projet, on se voit à télécharger 20 versions du même paquet parce que le projet dépend de 40 paquets qui utilisent 20 versions différentes du même paquet (sans compter les autres versions de paquets similaires, parce que bien entendu, ces 40 paquets qui ont besoin d'une même fonctionnalité, ne vont pas utiliser la même lib qui propose cette fonctionnalité).

L'installation de certains outils utilisant npm est hallucinant en terme de temps de téléchargement et d'installation. Sans compter que, puisque qu'il y a 20 versions d'un même paquet, alors on se retrouve avec ces 20 versions en mémoire et du code similaires exécutés bien entendu 20 fois au chargement (pour une seule instance de l'outils).

C'est un gachi de ressources hallucinant, tant à l'installation (bande passante &co, même si npm gère un cache), qu'à l'exécution.

Et je ne parle pas des nombreux paquets qui n'ont rien à voir avec JS, mais qui sont dans npm parce que leurs auteurs ont trouvé sympa de pouvoir installer leurs logiciel via npm. WTF.

PS: corollaire du problème de télécharger 20 versions d'un même paquet : les statistiques de téléchargement sur npmjs.org sont totalement bidons et ne veulent rien dire au final.

ici on mesure (veut mesurer) la technicité seule

Oui donc l'intitulé ne devrait pas être "meilleur dev de france" mais "meilleur pisseur de code de france".

pourquoi "un jour" ? Rust est stable maintenant. Ça en fait un concurrent sérieux selon moi.

ça existe encore ce truc ?

L'interface usine à gaz n'a toujours pas changé depuis 15 ans; C'est illisible en plus d'être moche…

Et pour ça, il y a des api et des outils existants pour les récupérer. Les wiki, c'est du git aussi. etc. etc..

Enlever des restrictions sur les produits pour vendre plus de services : c’est clairement leur direction actuelle, et à mon avis ils ont raison.

C'est tellement leur direction que leur offre cloud est dorénavant leur première source de revenu. Et que Windows n'arrive qu'en 4ième, derrière les jeux (xbox &co), et MS Office.

Ça commence à faire un petit bout de temps que MS ne l'ignore plus. Leur offre cloud Azure propose du linux depuis je ne sais combien de temps.

De la bouche même du PDG en 2014 : Microsoft Aime Linux.

Github ne peut pas vraiment proposer une UI pour ça : ça ne collera jamais avec les besoins de chacun. Il y en aura toujours pour se plaindre qu'ils n'ont pas besoin de tel ou tel champs, et d'autres qu'ils n'ont pas tel ou tel champs.

Je n'ai absolument pas le syndrome de Stockholm. Je sais juste reconnaître les qualités. Et github me convient, d'autant plus que, comme je viens de le montrer on peut récupérer les données et les réutiliser sans problème. Faut vraiment être aveuglé par son idéalisme pour ne pas voir que ce ne sont pas des problèmes.

Figure toi que j'utilise Github, mais aussi Gitlab. Le premier pour mes projets perso et open-source, le deuxième pour mes besoins professionnels, pour les projets de mes clients, en mode privé, parce que ces projets n'ont rien à faire sur github, même en dépôts privés.

Mais je n'utilise pas Gitlab pour mes projets perso parce que Github facilite le coté social et contributeur.

Et je n'ai pas toujours utilisé Github : pendant bien longtemps j'avais ma propre forge (sous Trac). Mais au bout d'un moment, maintenir tout ça (les mises à jour, le spam etc) me prenait trop de temps et les fonctionnalités ne correspondaient pas tout à fait à ce que je voulais… (bon, maintenant j'ai un gitlab à maintenir mais comme il est privé, j'ai moins de souci avec le spam ou autre).

les templates sont apparues il y a quelques jours …

Tu peux certainement récupérer tes données brutes sur Github, mais ça ne veut pas dire que tu pourras les réutiliser facilement, parce que si tu n'as pas le logiciel qui va avec tu vas devoir adapter (si c'est dans un format standard ça peut déjà grandement faciliter la tâche). Et Github ça n'est pas que git (qui lui est libre et décentralisé), c'est le système de revue, de bugs etc.

Pour les données, je ne pense pas que l'on puisse se faire du souci en ce qui concerne Github, tant à l'export (à partir de github), qu'à l'import (vers un autre outil).

• pour le code : c'est git. Donc tu as toujours l'historique sur ta machine. Export/Import : aucune difficulté
• issue/pull request : une api permet de tout récupérer au format Json. Un parser pour l'importer dans un autre outils n'est pas très compliqué. Et en cherchant, il doit déjà y en avoir pour certaines forges. Par exemple j'en utilise un qui rapatrie les issues sur ma machine et les mets en forme en html, ce qui me permet de les consulter offline. Sans parler du contenu textuel qui est en markdown, syntaxe prise en charge par de plus en plus d'outils (au pire, le markdown reste tout à fait lisible si il n'est pas interprété).
• wiki : c'est un dépôt git rempli de fichiers en syntax markdown. Pour exporter, un simple git clone suffit. Et à importer vers un autre outils, là encore, développer une moulinette ne serait à priori pas bien compliqué. D'autant plus que Github a libéré le code de leur système wiki (je n'ai plus le nom en tête). Suffit de l'installer donc.
• pages perso : le contenu est dans ton dépôt git (branche gh-pages), donc les données sont là. Pour la re-publication sur un autre serveur, installer jekyll et voilà.

Bref : récupérer les données, aucune difficulté, et pour les importer dans d'autres outils, non plus. Elles sont dans des formats standards (markdown..) ou parfaitement utilisable (structure json pour les issues) et très facile à exporter dans une base de donnée.

Le seul blocage qui pourrait y avoir, serait le blocage par Github des API, empêchant de récupérer les issues. Ça peut se régler par l'installation dès maintenant d'un script aspirant régulièrement les données, et si un jour github ferme son api, il sera temps de fermer son compte et d'aller s'installer ailleurs ;-)

En effet il y a le mot colorisation syntaxique mais en l'occurrence je voulais utiliser un verbe, or colorisyntaxiser n'existe pas encore et j'espère qu'il n'existera Jamais.

En total contradiction avec toi même, puisque tu utilises "highlighter", qui n'existe pas non plus, et qui, j’espère aussi, n'existera jamais non plus.

C'est comme en programmation, quand on n'arrive pas à faire ce qu'on veut, on change d'algorithme. En français, si on n'a pas les mots pour exprimer ce que l'on veut dire, on change de formulation, et on n'invente pas des mots n'importe comment. Et surtout on ne sort pas des excuses à deux balles comme tu viens de le faire.

Alors arrêtez d'être passéiste svp

Ce n'est pas du passéisme. C'est juste du respect de la langue et du respect envers tes lecteurs. Tu nous invente des mots n'importe comment. Alors qu'on peut très bien s'exprimer en français correctement pour exprimer ce que tu voulais dire. Si il n'y avait vraiment pas d'alternatives, pourquoi pas, mais là…

oui c'est vrai en plus /o\

d'highlighter

mon dieu quelle horreur. C'est si dur que ça que d'écrire français ?

permettant d'avoir la coloration syntaxique pour le code Vulkan.

Et pendant qu'on y ait : s/plugin/greffon

nom de code du projet durant son développement.

Pourquoi l'avoir désactivé dans Debian tout en laissant le code ?

Parce que le mainteneur du paquet a autre chose à faire ? Et que cela ne doit pas être aussi facile que tu laisses penser, que de supprimer des milliers de lignes de code (que le mainteneur ne doit pas connaitre; moi même, ex-contributeur, je ne connais pas) ? Avec les bugs potentiels que cela peut générer..

Et puis du coup, ce ne serait plus du patch correctif ou d'adaptation, mais ce serait transformer le code du navigateur suffisamment profondément pour faire dire à Mozilla qu'il ne s'agit plus de Firefox, et donc ne mérite pas de l'appeler "Firefox".

Oups, je ne suis pas en forme ce soir :-/ Pardon Sylvestre.

Désolé, mon titre est bancal, j'ai mal relu.. Un modérateur pourrait-il supprimer le mot "être" ? merci d'avance :-)

On comprend qu'ils abandonnent si c'est par manque d'utilisateurs,

En fait, il y a eu un problème de l'oeuf et la poule. Et je me demande si ils s'en sont rendu compte…

Selon eux (voir ce lien qui explique toutes les raisons), c'était pas mal buggé (même si je n'ai jamais vraiment eu de problème avec), donc ils ne l'ont pas trop mis en avant. Et donc forcément, peu d'utilisateurs. Donc ça n'encourage pas à corriger les bugs, donc ça n'est pas mis en avant, donc peu d'utilisateurs etc..

non, pas aux dernières nouvelles