Laurent J a écrit 2938 commentaires

même de récupérer les sources sur le site officiel, d'ailleurs

Non mais là, désolé de te le dire, tu pousses un peu loin. Une ligne de commande à taper pour récupérer les sources. c'est indiqué noir sur blanc dans la doc. Tu peux même télécharger direct sans cloner. Je ne sais pas ce qu'il faut de plus sérieusement. Ta remarque (et d'autres de tes commentaires), me fait penser de plus en plus que le problème en fait se situe entre la chaise et le clavier. C'est à dire une incompétence sur le fonctionnement d'un gros projet comme Firefox (non, désolé, désactiver des trucs pas désactivables dans un gros projet, ça se fait pas en indiquant 2 options et faire deux hack pourri), et probablement une inexpérience en développement.

En fait, je te trouve bien naïf. Par exemple quand tu dis que tu trouves Firefox trop lent et que tu veux compiler pour tenter de trouver toi-même là où ça coince. Sérieusement. Des millions de lignes de codes. Des millions. Provenant de libs diverses et variées. Un navigateur, c'est pas un "hello world". Y a des centaines de paramètres qui rentrent en jeux dans les perfs de Firefox (la manière dont il boot, le moteur JS, le moteur de rendu, la pile réseau, les lib graphique, Cairo, GTK, Sqlite, le code des sites web, le système de garbage collector, XPCOM etc..). Bref, tout un programme (à lire absolument si tu veux te plonger vraiment sur le sujet). Des personnes travaillent à plein temps dessus, et toi tu espères (sans rien connaître au projet et en gueulant ici) trouver magiquement le code responsable des mauvaises perfs avec un build en mode debug et ton gdb.

L'idée de vouloir améliorer les perfs, c'est sympa, et ton aide sera la bienvenue. Mais seulement si tu t'aides d'abord toi même, (en ne restant pas dans ton coin et en demandant de l'aide). Et commence d'abord par faire un truc simple plutôt que de vouloir révolutionner le monde. Bref, rester humble et laisser de coté son ego.

Commence par apprendre comment fonctionne le projet, apprend à utiliser les outils, documente toi, pose des questions sur les canaux de discussions de Mozilla. Je t'ai déjà donné les billes pour ça.

Bref, faire comme pour tous projets libre dans lesquels on veut s'investir.

Super. Devoir aller chercher dans l'océan about:config une valeur qui devrait être accessible via l'ihm…

Désolé, je n'ai pas dû comprendre ce que tu voulais faire exactement. Tu veux faire un fork de Firefox avec tes histoires de build pour n'avoir que des fenêtre seules. Je t'indique une piste qui t'évite cette pénible étape et tu n'es pas encore content ??

Pour le build, non, il ne suffit pas de les suivre à la lettre.

c'est pourtant ce que je viens de faire à l'instant…

wget -q https://hg.mozilla.org/mozilla-central/raw-file/default/python/mozboot/bin/bootstrap.py && python bootstrap.py
hg clone https://hg.mozilla.org/mozilla-central
cd mozilla-central
touch mozconfig
./mach build

20 minutes plus tard, j'ai pu lancer firefox.

Maintenant, si tu changes plein de trucs, oui, le build peut planter…

Chez moi, en désactivant toutes les "fonctionnalités" qui intègrent le support du son et/ou de la vidéo, j'ai encore des dépendances à webm qui traînent.

Peut-être as-tu oublié d'indiquer d'autres flags, ou alors qu'il y ait un bug de compil. Je doute que la désactivation de ce genre de fonctionnalité soit beaucoup utilisée et donc personne chez Mozilla ne se rend compte de ce genre de problème.

Parles-en sur les newsgroup ou sur irc.mozilla.org #developers. Et sinon http://bugzilla.mozilla.org. ça sera je pense plus constructif pour toi…
```

Je ne comprend pas. Firefox te permet d'ouvrir tes pages webs dans une fenêtre séparée. Je crois même qu'en modifiant la pref browser.link.open_newwindow ça peut se faire automatiquement quand on clique sur un lien… Il y a d'ailleurs une extension qui semble faire ce que tu veux.

Pour le build, y a de la doc, à priori, suffit de suivre les instructions à la lettre. À moins que tu ais un système exotique ?

Ils ne sont plus le client majoritaire de Mozilla depuis quelques semaines

Oui, il y a des bugs non corrigés existants depuis des lustres.

Et non, ce n'est pas volontaire de la part des développeurs ou de leur hiérarchie, de laisser ces bugs pourrir.

C'est juste qu'ils n'ont pas le temps de tout faire. C'est juste parce qu'un projet comme celui là, il y a des milliards de choses à faire. Et qu'il y a des priorités.

Et non, ne pas développer Hello ou autre trucs qui vous semblent futiles dans le navigateur, ne vas pas donner plus de temps pour corriger les bugs que tu pointes. Tout simplement parce que ce ne sont pas les mêmes personnes qui travaillent sur ces parties. Et ce ne sont pas les mêmes personnes, parce que cela n'exige pas les mêmes compétences.

Pour les problèmes CSS, cela exige une connaissance sur le moteur de rendu, donc des compétences en C++, en algo de reflow et cie, en architecture d'un moteur de rendu HTML, et surtout, une connaissance du code source existant (très complexe). Faire un Hello, ça exige des connaissances en JS/HTML pour l'interface, et C++ pour l'implem de WebRTC, des connaissances poussées sur WebRTC (qui est une spec bien complexe ). Faire un outil de debug, ça nécessite aussi du JS/HTML pour l'UI, mais aussi des connaissances poussées sur le moteur JS (en C/C++), bien complexe lui aussi, pour implémenter par exemple les API de debugs etc..

Bref, chacun a sa spécialité. Le nombre de personne qui ont une connaissance approfondie de l’entièreté du code de Gecko (je ne parle que de Gecko, pas de l'interface de Firefox et ses composants périphériques comme Hello etc), on doit les compter sur les doigts des deux mains. Si ce n'est qu'une seule.

Moi par exemple dans Gecko, ma spécialité était le serializer HTML/XML, l’implémentation des élements DOM XUL, et l'éditeur HTML (le truc qui sert à avoir des champs de saisie dans une page web, ou à pouvoir éditer une page en wysiwyg avec le mode contenteditable). Mais je suis totalement incapable de toucher à un truc dans le layout engine (css et cie quoi), ni au moteur JS. Au delà de savoir si j'aurais eu suffisamment les compétences pour toucher à cette partie (très complexe), je n'avais surtout pas le temps de me plonger dedans (en tant que bénévole). Ce à quoi je contribuais m'en prenais déjà énormément.

Et sur les parties sur lesquelles je contribuais, il y a là aussi des dizaines de bugs non résolu depuis des lustres : pas le temps de tout corriger. Il faut faire alors un choix. Ok ce bug A emmerde quelques utilisateurs, et il est là depuis des lustres, mais il y a ce bug B, plus récent certes, mais qui emmerdent beaucoup beaucoup plus de monde. Donc corrigeons ce Bug B. J'aimerais bien corriger aussi le bug C, mais là, il n'y a pas énormément de tests sur le code existants, et ce qu'il faut modifier risque de casser plein de trucs. Donc ça va prendre énormément pour développer tous les tests. Ah oui mais là le truc a un comportement bizarre : bug, oubli ou feature mal spécifiée ? Le bug C que je croyais pouvoir corriger en quelques heures va me prendre des journées entières, parce qu'il va falloir que j'étudie du code source et des specs à tire-larigo. Bon ben le bug C, ça sera pour quelqu'un d'autre. Ah, et puis y a le bug D. Trop important. C'est une feature totalement nouvelle dans HTML5, que les développeurs veulent tout de suite parce que trop kikoolol et que les autres nav ont déjà implémenté. Donc allons-y pour le bug D.

etc. etc. etc..
Voilà à quoi peut ressembler les contributions d'un bénévole. Pour un employé Mozilla, ils ont moins de latitudes à choisir. Faut qu'ils développent les nouvelles features. Parce que bon, y a des râleurs qui se plaignent du retard en HTML5 etc, alors faut qu'on avance. Hein ? quoi ? ah, faut aussi corriger les bugs vieux de 8 ans ? Ah bah oui mais faut savoir ce qu'ils veulent aussi…

Firefox est un gros projet. Et comme tout gros projets, il y a des choses qui ne sont pas corrigés, parce qu'il y a des choses plus prioritaires que d'autres, parce que le nombre de dev travaillant sur une partie n'est pas illimités, parce qu'un dev travaillant sur une partie n'est pas forcément compétent pour travailler sur une autre partie.

Donc voilà. Ok, y a 3 bugs qui t'agacent. Je te comprends. Moi-même j'en ai. Mais pas les même. Bref, y en a des centaines.

Mais je te rassure, c'est pareil ailleurs : il y a aussi des milliers de vieux bugs non corrigés sur Webkit concernant CSS. Idem sur les autres.

Ce sont des projets trop complexes, impossible de tout corriger, de tout s'occuper. Surtout pour une organization comme Mozilla qui est touuuuute petite à coté de ses concurrents…

Plusieurs raisons pour une fonctionnalité désactivée par une pref :

1) elle est en cours de dev, elle est à tester, des bugs subsistent ou l’implémentation n'est pas complète
2) spécification W3C encore instable et/ou des points de la spec ne sont pas clairs
3) feature non standard, réservée à certaines plateformes (c'est le cas par exemple pour l'API TCP socket, activée seulement dans Firefox OS pour les applis privilegiées). Ils attendent qu'une spécification émerge et devienne stable avant de laisser tout le monde l'utiliser. Ceci pour éviter au final qu'il y ait des trucs en -moz-* (css) ou moz* (js) qui trainent dans le code des sites web (et qui sont cassés par la suite parce que plus implémenté ou comportement changé). C'est une nouvelle politique de publication des nouvelles fonctionnalités.

Non il a raison. C'est implémenté depuis Firefox 25. C'est juste que pour le moment, c'est désactivé dans les releases officielles via une pref media.mediasource.enabled.

Mais le truc c'est qu'il travaille tous le temps avec des builds non stable. Dans lesquels c'est activé) :-p. Il a juste pas remarqué (ou oublié) que c'était pas dans la stable ;-)

Et oh, miracle, quand on met cette pref à true, youtube est beaucoup plus content :-p

Déjà, ne pas pas confondre Hello (nom de code "loop", utile pour s'y retrouver dans about:config ;-), et WebRTC.

WebRtc est une technologie web : n'importe qui peut faire son propre serveur webrtc, et donc son propre service. Pas besoin de Hello pour ça. rechercher sur google les quelques libs Webrtc opensource qui facilite le développement de son "site webrtc".

Hello est service, basé sur webrtc. Mozilla propose donc son propre serveur webrtc. Les sources sont disponibles !. Et tu peux dans les prefs du navigateur indiquer donc ton propre serveur (voir les prefs loop.* dans about:config).

Mais le souci de webrtc (la techno), c'est que tu dois avoir un serveur pour la "découverte" des autres utilisateurs (ensuite la communication se fait directement entre les deux clients, si les proxys/nat le permettent). Ce qui veut dire que si tu as ton propre serveur pour Hello, tu seras bien seul (ou alors contacter tout tes amis pour qu'ils configurent Firefox correctement)… L'alternative est donc d'implémenter son propre service (donc sans Hello) : une page web quelque part + un serveur pour la gestion des users, et c'est parti. C'est comme ça que font beaucoup de provider. comme http://Talky.io (basé sur des libs opensource d'ailleurs).

Ce qui serait bien, c'est que les serveurs d'annuaires puissent communiquer entre eux, pour que si tu contacts l'un deux, il puisse te mettre en relation avec un utilisateur qui est enregistré sur un autre serveur. Bref un truc à la SMTP/XMPP, coté serveur. (mais c'est hors scope webrtc).

7% d'écart, c'est pas la mort…
Euh… Quand même, si! Surtout pour un navigateur qui se veut OS, vaut mieux supporter plus que l'autre même, en avance, car FFOS (par exemple) n'a pas d'autres API.

C'est pas fini cette mauvaise foi ? Sans dec !

Tu as regardé ce qui manquait ? La plupart des trucs, ce sont des choses rarement utilisée, et sur lesquels les autres navigateurs sont aussi à la traine (IE pour pas le cité). Le seul truc qui coince il est vrai pour des développements "classiques", ce sont quelques fonctionnalités sur les formulaires, mais franchement rien de très méchant.

Et html5test est TRÈS loin d'être exhaustif. Il manque les dizaines de webapi implémentées dans Firefox mais pas dans Chrome.

Le support de Javascript ES6 est meilleur dans Firefox que dans Chrome (et encore bien meilleur si on tient compte des trucs ES6 supportés par Firefox depuis des années mais qui manquent des petites adaptations pour être conforme aux dernières évolutions de la norme). Et aux dernières nouvelles le moteur JS de Firefox est le plus rapide à la plupart des tests.

Bref, Gecko n'est pas un "vieux" moteur.

tu veux tester une fonctionnalité hype? faut aller sur Chrome

Ah ? Je veux utiliser par exemple les proxy en JS (très utile pour mocker des objets, pour implémenter des itérateurs spécifiques etc). Non, je ne vais pas sur Chrome. mais sur Firefox.

je veux faire du MathML (ouai ok, c'est pas super hype), je vais sur Firefox, pas sur Chrome.

je veux utiliser les API (ambiant light, proximity etc) qui me permettent de modifier le comportement de mon appli pour qu'elle soit moins gourmandes en énergie quand il le faut ? J'utilise Firefox, pas Chrome.

Je veux communiquer au niveau TCP socket, pour utiliser des protocoles autres que HTTP ? Je vais sur Firefox(OS), pas Chrome. Même si cette API n'est pas standardisée, cela montre tout de même (ainsi que plein d'autres API) une avance non négligeable de Firefox sur certains domaines.

Les web apps ça a déjà pas marché avec…

Et bien sûr, ce n'est absolument pas parce que les techno web de l'époque n'étaient pas aussi mature qu'aujourd'hui.

Sérieux. Comparons ce qui est comparable.

Tu compares des fabricants de mobiles avec un éditeur d'un OS. Tu compares des solutions propriétaires pour la plupart, avec une solution Open-Source.

Quand ce n'est qu'un fabricant de mobile qui pousse une techno (propriétaire), oui, il y a beaucoup de chance que ça plante.

Quand ils sont plusieurs à pousser un même OS libre sur leur matos, tout de suite, ça va beaucoup mieux. La preuve avec Android.

On mettra Apple à part, car ils ont su innover au niveau ergonomie. Et si ils ont abandonné les web-apps, c'est plutôt parce que ça les empêchait de contrôler ce que l'utilisateur pouvait installer, et donc monnayer l'installation des applis.

et aujourd'hui ça ne marche toujours pas avec FirefoxOS. Quelle surprise.

Je ne comprends pas cette réaction que je vois dans bon nombre de commentaires. Le truc est à peine sorti, n'a pas eu le temps de faire ses preuves, que tout de suite, il y en a pour conclure "ça ne fonctionne pas".

J'aimerais bien savoir sur quoi repose ces conclusions.

Apparemment vous vous fiez tous au contenu du MarketPlace. C'est, selon moi, un très mauvais indicateur.

En effet, les premiers téléphones Firefox OS vendu au grand public au monde, ne l'ont été qu'il y a tous juste un an et deux mois au Brésil. UN AN. Assez rapidement, il l'a été aussi dans quelques autres pays d'amérique latine, et d'europe de l'est. Et il n'est arrivé en France qu'en septembre dernier, et encore, il n'est pas vendu par des opérateurs (donc des ventes qui restent confidentielles).

Comment pouvez-vous donc dire que "ça ne marche pas" ?

Oui, les développeurs ne sont pas précipités pour développer des applis pour Firefox OS, parce que déjà le marché est limité (pays émergeants au niveau smartphone), et de plus, pas forcément pour les marchés qu'ils visent. Les développeurs sont surtout embauchés par des boites qui ont l’Europe et l’Amérique du nord comme cibles, non ? En tout cas, la connaissance que vous semblez avoir du marché, c'est celui que vous connaissez (et encore), c'est à dire celui de l'Europe.

Et puis si il y a peu de développeurs, c'est probablement aussi qu'ils ne sont pas au courant aussi tout simplement. Mozilla n'a pas la force marketing que peut avoir Google quand il fait la promotion de son Android.

Bref, peu de développeurs, donc peu d'applis.

Pour le moment. Ce n'est que le début. Des dizaines d'opérateurs et constructeurs ont annoncé sortir des devices sous Firefox OS (voir toutes les news sur le blog mozilla) : téléphones, tablettes, tv connectés etc..

Avant d'annoncer une mort qui n'a pas lieu, je pense qu'il serait bien de patienter que le produit devienne mature et soit vendu dans une majorité de pays, en particulier en europe et amérique du nord.

L'app store d'Android et d'Apple ne se sont pas rempli en 2 jours… Android n'a pas "explosé" ses ventes les premières années..

Tout dépend comment l'appli est packagée par son développeur. Ses fichiers ne sont pas "retéléchargés par la suite" seulement si elle a été distribué dans un zip.

Le manifest de l'appli peut indiquer un simple lien vers l'appli hébergée sur un serveur web, au lieu d'un lien vers un zip. Donc il te faudra avoir une connexion internet pour l'utiliser. À moins que l'appli utilise toutes les fonctions appcache/offline de HTML5. Dans ce cas il te faudra une connexion internet seulement au premier lancement.

Il y a une différence fondamentale entre Camino (le navigateur sur MacOS dont tu parles), et Firefox/Thunderbird.

Pour le premier, l'interface utilisateur était réalisée nativement avec Cocoa. Gecko n'était utilisé que pour les pages web.

Dans Firefox et Thunderbird, l'interface utilisateur est réalisé en XUL (un dialect XML) + CSS + Javascript, et est donc affiché par Gecko. Gtk2 (ou gtk3 ou qt3) ne servent donc qu'à instancier des fenêtres (vides, puisque le contenu est pris en charge par Gecko avec XUL), à récupérer des infos graphiques comme les couleurs par défaut des widgets graphiques (pour une meilleur intégration visuelle via CSS), à dialoguer avec l'environnement graphique, comme par exemple à avoir des boites de dialogue pour ouvrir/enregistrer des fichiers, gestion presse-papier etc. Bref, la partie graphique de ces toolkits est peu utilisée en fin de compte. Contrairement à Camino.

je dirais plutôt un inconvénient selon moi, surtout si il y a plusieurs utilisateurs.

un wiki, c'est censé être modifié très souvent, le contenu bouge etc. Cela veut aussi dire qu'une modification dans une page = un commit (que ce soit dans un dépôt git ou un autre système d'archivage).

Résultat(1) : on se retrouve avec des centaines de commits (dont beaucoup ce sont des petites corrections d'orthographes ou autres). Et bien souvent, les utilisateurs ne mettent pas de "message de commit" (y compris moi, par flemme), donc on se retrouve avec des commits ayant le même intitulé par défaut.

Si le contenu du wiki est dans le même dépôt que le code source, on se retrouve alors avec un historique complètement illisible. Ce qui annihile tout intérêt de versionner le code source.

La documentation dans le même dépôt que le code source, pourquoi pas (je le fais bien pour slimerjs), mais faut pas que ce soit un wiki (c'est à dire, modifiable par une interface web). Et faut que ce soit une doc qui évolue en même temps que le code, donc très proche du code. Par exemple, une doc de référence (api etc) ok. Pour des tutoriaux ou manuels : je préfère un dépôt à part, car au final ils ont leur vie propre, et n'ont pas le même rythme de vie (par exemple, pour la documentation d'une lib, on va écrire les tutoriaux qu'une fois que l'api est relativement stable, et pas au fur et à mesure, sinon on risque de réécrire des parties du tuto 50 fois -> perte de temps).

(1) ceci est une constatation que je fais à partir de wikis que je possède ou possédait, ouvert à plusieurs personnes.

En ce qui me concerne, j'ai adopté Gitlab parce que c'est ce que j'ai trouvé de plus complet avec une interface et des fonctionnalités modernes.

Je l'utilise pour les projets de mes clients et les projets internes. J'ai aussi installé gitlab-ci pour lancer des tests auto et déploiement automatique. (Je n'utilise pas Jenkins car je trouve que c'est une horreur sans nom au niveau interface, d'un autre temps, et super lourdingue à l’exécution, et si tu veux faire un truc pas supporté par un plugin, c'est la méga galère à configurer).

Par contre pour les projets open-source, j'utilise Github. C'est plus facile pour les contributeurs, et je n'ai pas envie de mélanger projets privés/projets publics. Pour le déploiement continue de mes projets open-source (packages, site web etc), j'ai installé Strider-cd sur mon serveur.

Et pourquoi pas un port en GTK3 ?

Ce n'est pas du ressort de Thunderbird, mais de la plateforme sur laquelle il repose : Gecko. Et c'est en cours.

En ce qui concerne Qt, pareil, c'est du ressort de Gecko. Il existe un port Qt de Gecko, mais je ne sais pas si il est vraiment maintenu.

Pareil, j'aimerai bien comprendre en quoi le support openVZ pose problème avec le noyau 3.x de Linux dans Proxmox ? Je commence à en avoir marre de garder un vieux noyau 2.x. Ça devient handicapant : on ne peut pas utiliser certaines technos récentes comme Docker.

OK ton argument du coup c'est de mettre un couteau sous la gorge à tout le monde ?

pas compris le rapport avec ma question, et d'ailleurs tu n'y a pas répondu. Donc je repose la question : Comment Mozilla pourrait gagner l'argent nécessaire à ses activités, tout en devenant une fondation "pure" au niveau de l'esprit du libre ?

Ma question est sérieuse !

(c'est quand même bizarre, à chaque fois que je pose cette question, je n'ai jamais de réponse censée).

Ça se voit que tu dis ça sans rien connaître

Ah mince. Tu veux dire que le gars avec qui j'ai travaillé dans le même bureau pendant 4 ans m'a menti et n'est pas co-chairman du groupe CSS au W3C et que donc tout ce que je sais du W3C est erroné ??

Alors oui il y a des personnes "indépendantes" (comme Fantasai au groupe CSS) qui sont des "invités expert", qui participent donc activement au développement des standards. Oui j'ai un peu forcé le trait dans ce dialogue qui est fictif comme je l'ai indiqué. Mais globalement c'est ce qui se passe au final. Si un "implémenteur" ne veut pas implémenter une propriété CSS par exemple, pour de multiples raisons ("ça ne sert à rien pour nous", "c'est mal spécifié", "c'est trop compliqué") il ne le fait pas, le fait savoir. C'est déjà arrivé (même chez Mozilla, comme par exemple les fontes SVG), et ça arrivera encore.

Et si cet "implémenteur" représentait 80% du marché (qui est une statistique complètement fictive pour le moment, je rappelle), et bien la majorité des développeurs web n'utiliseront pas cette propriété.

Bref, au final, si il y a un acteur au W3C qui a le monopole sur le web, qu'il y ait des experts indépendants ou pas dans les groupes des travails ne changera rien : il fait ce qu'il veut sur le web.

C'est pour cela qu'il est important qu'il y ait plusieurs moteurs de rendus pour le web, qu'il y ait plusieurs navigateurs, et donc que Mozilla doit exister, et qu'il faut que Mozilla ait une part de marché non négligeable (sans pour autant avoir le monopole, ce n'est pas l'objectif de Mozilla d'ailleurs).

Je sais que certaines contributions proviennent de Mozilla, mais de la à arguer que c'est dû à son nombre d'utilisateurs… ça me paraît un peu douteux.

Ah ? si Mozilla représentait seulement 1% des utilisateurs, tu crois que ses représentants au W3C aurait autant de poids, autant de crédibilité dans les débats dans les groupes de travail ?

Discussion fictive:

Mozilla (1% de pdm): "mes utilisateurs/développeurs trouvent qu'il serait bien d'avoir telle propriété CSS/HTML parce que ceci cela…"

Google (80% de pdm): "(LOL) Je n'ai pas eu de retour sur ce type de problématique, je ne pense pas que ce soit intéressant pour mes utilisateurs. De toute façon, j'en ai pas besoin dans Gmail/Google+/GTruc, donc je ne l'implémenterai pas. je préfère qu'on passe du temps à discuter sur cette propriété trucmuche (dont j'ai absolument besoin pour gmail), ça me semble plus important pour l'avenir de Google^W du Web."

beaucoup de projets libres sont fait par des bénévoles, et également des entreprises, qui se financent autrement qu'en vendant leurs utilisateurs.

Des exemples ? (à gros budgets si possible).

J'aurais préféré un autre compromis.

Ah ! Je suis très intéressé (et Mozilla aussi) ! Vas-y, on t'écoute !

Attention, ne nous sort pas des solutions qui ne permettent pas d'embaucher à temps plein les quelques centaines de développeurs qui bossent sur Firefox, FirefoxOS, MarketPlace, Firefox Sync, Firefox Android, DevTools, et les dizaines d'autres projets R&D (ou pas), comme les problèmes de Privacy, les formats libres (audio, video…), les problèmatiques de certificats TLS gratuit etc…

Si ils avaient moins de revenus, Mozilla pourrait certes couper dans tous ces budgets R&D, mais cela voudrait dire qu'il serait plus compliqué de se maintenir au rythme de la concurrence (Google Chrome etc…)… Et puis avec moins de budget, donc moins de projets et de participation au développement des technos du web (W3C et cie), du coup, Mozilla deviendrait un acteur mineur. Le logiciel libre en prendrait un coup je pense (dans le domaine des navigateurs).

En pratique, je trouve que les certificats auto-signés sont plus fiables et plus sécurisés. On risque une man in the middle a la première connexion, mais après, on est vraiment sûr de notre interlocuteur.

Oui et non. Si le certificat change, ton navigateur râle de nouveau. Mais tu ne sais pas si c'est à cause d'un MITM, d'un proxy pourri ou si c'est parce que le propriétaire a vraiment changé son certificat.

je risque a tout moment un man in the middle par quelqu'un qui a mis l'autorité de certification dans sa poche

Tout comme pour un certificat auto-signé.

ajout d'une table des matières pour les articles longs ;

Ça c'est juste une histoire de présentation, pas de syntaxe (puisqu'il suffit de répertorier tous les titres). Donc au final pas de rapport avec Markdown :-)

Projet super cool, je plussoi !

Mais… c'est quoi la charge ? même pas un petit robot , un personnage lego, une bière, une navette lego, ou encore une chaise ?

les traditions se perdent, je vous jure.. :-)

Non mais sérieux, arrêtez vous tous avec vos "github ça pue c'est proprio". Vous êtes totalement ridicule et montrez votre incompétence manifeste sur le développement d'un service comme Github.

Github, et toute appli qui est utilisée par des milliers d'utilisateurs simultanément, ce n'est pas quelques dizaines de fichiers de code source en [ici ton langage preféré] qu'il est possible magiquement de libérer sous licence libre.

Le "site" github n'est qu'une facade, la partie visible de l'iceberg et franchement libérer son code source ne servirait à personne, principalement parce l'appli est fortement liée à une multitude de services et outils sous-jacent, taillés, configurés, organisés, architecturés, pour supporter chaque jour des millions de requêtes http, des milliers d’exécutions de jobs en tout genre etc…

Vous voulez que Github libère le code source ? Ok, vous allez vous retrouver avec des centaines de pages de doc pour installer l'infra nécessaire pour faire fonctionner le site github, des dizaines de source de jobs dont vous ne saurez que faire parce que trop spécifique à l'infrastructure déployée par les gens de github. Et puis au final, vous allez vous rendre compte que, comme beaucoup de société comme Github, ils utilisent beaucoup d'outils existants (au hasard, Redis), et ont déjà libéré depuis longtemps des composants/outils (ex: leur système wiki, Resque et j'en passe). En notant que ce qu'ils ont libéré, ce sont des choses qui sont réutilisables ailleurs.

Libérer par exemple le site github serait comme libérer le tableau de bord d'une centrale nucléaire. ça ne servirait à rien, puisque tu n'aurais pas le reste de la central nucléaire (c'est à dire, dans le cas de github, toute l'infra serveur et réseau de github). Et que bien sûr, ton tableau de bord, étant spécifique à une installation de central nucléaire, tu ne peux l'utiliser pour autre chose.

Pour résumer : non, Github ce n'est pas UN logiciel comme gitorious ou gitlab. c'est un service d'une part, et d'autre part (et avant tout), c'est une infrastructure complexe, composé d'une multitude d'outils et composants, capable de supporter un trafic réseau très lourd, et capable de traiter un volume de données hallucinant. Une infra, ça ne peut pas se libérer.

Bref, Github, c'est déjà pas mal libre, et c'est déjà bien suffisant, car le reste n'aurait strictement aucun intérêt pour personne. Pour preuve, Gitlab au début, était basé sur la plupart des composants libérés par Github, ils n'ont eu qu'à développer l'interface HTML. Jusqu'à ce qu'ils se rendent compte que ces composants n'étaient pas forcément adaptés à ce qu'ils voulaient faire, parce que leur objectif n'est pas de fournir une plateforme de dev collaborative pour des centaines de milliers d'utilisateurs, mais pour des installations plus modestes et qui soient plus simples à installer/à administrer. Et ils ont fini par remplacer des composants de github par des trucs plus adaptés…