Laurent J a écrit 2933 commentaires

Tient d'ailleurs, en parlant de tablette. Curieusement, Android, IOS et autres OS pour smartphone/tablette ont nativement du multi-bureau. Et à priori, tout le monde aime vu le succès.

bon nombre de développeurs (beaucoup, vraiment beaucoup) sont sous Windows et n'ont jamais eu la moindre idée d'avoir l'utilité de la chose,

À mon avis, bon nombre de ces développeurs ne connaissent pas le multi bureau, et/ou n'ont en tout cas pas testé la chose (puisqu'ils ne l'ont pas installé comme tu le dis toi même). Ce genre de chose, ça s’apprécie à l'usage. C'est comme les tablettes, à la sortie de l'ipad, pas beaucoup de monde en voyait l'usage. Maintenant beaucoup en ont une, bien souvent après en avoir testé une.

et bon nombre de développeurs deandent en premier 2 écrans que d'avoir les droits admin pour (ou faire) installer un multi-bureau.

Ils demandent un deuxième écran pour quoi ? Pour avoir de la place. C'est justement ce qu'un multi bureau fourni : de la place. et beaucoup, puisqu'on peut avoir le nombre de bureau qu'on veut (dans la limite de la mémoire disponible).

Tu n'as pas besoin d’apache, ni de module, ni de cgi.

Si c'est pour tester, PHP aussi embarque un serveur web. pas besoin d'apache, ou autre pour exécuter une appli php.

Je développe et j'ai effectivement 2x 24'' de la mort qui tue.

Et je continue d'utiliser le multi bureau. Ça permet d'organiser mes environnements de travails : un bureau pour le dev (éditeur, console etc..), un autre pour le navigateur (plusieurs fenêtres), un autre pour tout ce qui est communication (irc, thunderbird…), un autre pour des trucs divers, ou un autre projet etc.. Bref, quand je suis sur un bureau précis, je n'ai pas 15 fenêtres qui n'ont pas de rapport avec ce que je fait, qui viennent me déconcentrer dans ce que je fais (parce qu'elles seraient mal placés, qu'il faut les cacher, les rouvir, les cacher, les déplacer etc…). Un raccourci clavier et je retrouve un autre environnement avec les fenêtres qu'il me faut, là où elles étaient. Personnellement, je gagne un temps fou.

Bref, ce n'est pas parce que j'utilise encore le multi bureau que je suis un vieux chnoque. En 2014, oui, le multi bureau reste très pratique (surtout avec les raccourcis clavier qui vont bien avec). Peut-être pas pour toi. mais pour d'autres oui.

Chacun sa manière de s'organiser.

(c'est toujours drôle de voir comment tu prend ton cas pour une généralité dans tes commentaires).

J'en connais chez PHP qui doivent pleurer.

Comme si faire du C# c'était le graal. Tu ne me fait pas pleurer, mais rire plutôt.

Ce n'est pas parce que PHP traine encore des boulets syntaxiques ou d'interface de programmation, qu'il faut les utiliser. Le langage a énormément évolué ces dernières années.

On peut coder très proprement en PHP. On peut faire du MVC très propre, ou tout ce que tu veux très propre. Ce n'est pas parce qu'il y a encore des scripts pourris fait par des débutants, que PHP nous oblige à coder comme des porcs. D'ailleurs, dans n'importe quel langage tu peux coder comme un porc.

Bref, ce n'est pas parce maintenant on peut faire du C# MVC truc muche sous linux que je vais m'y mettre, encore moins si c'est pour faire plus "hype" ou pour crâner. Je pense que la majorité des dev PHP ont rien à battre de se que peuvent penser les autres sur PHP. Franchement, ceux qui se la pète parce qu'ils utilisent un langage soit-disant "plus pur", je leur ris au nez. (et je vais m’arrêter là sinon je vais commencer à dire des grossièretés).

Le principal dans le développement, c'est de produire une appli qui marche, qui corresponde aux besoins demandés, et qui soit codée proprement pour être maintenable (et PHP n'empêche pas de faire tout ça). La technologie utilisée, on s'en tape.

Mettre à jour quoi? PHP ?

non, l'appli en PHP (si elle a cette fonctionnalité).

M'enfin, ce n'est pas forcément trivial avec apache+mod_ph : il faut que les fichiers de l'appli soit installée avec les droits en écriture pour le user d'apache.

Du coup, pour ce genre de feature, vaut mieux installer php en mode fcgi (avec php-fpm), pour lequel on peut donc indiquer un user d’exécution différent d'apache (donc en principe le user qui s'occupe de la maintenance de l'appli).

Donner une adresse locale à un site n'a de sens que si le visiteur comprend de quelle localité on parle.

Dans 90% des cas, je dirais qu'un visiteur comprend la signification d'un nom de domaine qu'une fois arrivé sur la page web. jelix.org, tu crois que ça parle à beaucoup ? non. Y a tellement de noms "bizarres". C'est pareil pour les tld. Et c'est tant mieux je dirais. Vive la diversité.

pas sûr que tout le monde fasse le lien entre bzh et la Bretagne.

Et alors ?

Crois-tu que tout le monde fait le lien entre kernel.org et le noyau linux ? (kernel étant un mot très général, et encore il est en anglais, donc ça parle encore moins à des non-anglophone).

Tu ne vois pas l’intérêt, mais d'autres le vois. Ça ne veut pas dire que ce soit mal. Les tlds, ce sont comme les noms de domaines en général : ça ne parle qu'à un "petit" nombre de gens au final.

parce que bientôt on aura une flopée de TLD tous plus imbitables les-uns que les-autres, du coup plus personne ne fera l'effort d'aller voir ce qu'est un TLD.

Parce que les gens allaient voir ce qu'était un TLD ??? (par gens, je parle des 7 milliards d'êtres humains moins les quelques centaines de milliers de nerds).

S'ouvrir au monde et aux besoins "locaux", c'est bien.

À t'écouter, il faudrait juste un .com au final. Quel intérêt ?

Facile, avec une Delorean qui bouffe du 2.21 gigowatt/s.

Ben voila : on sent qu'il faut caser du HTML/JS partout car c'est la techno connue, et on ne regarde pas si elle répond le mieux au besoin générique des smartphone

C'est vrai que les milliers d'applis mobiles fait en HTML/JS (déguisées en appli natives pour certaines), n'ont absolument pas montré le besoin. Leurs limites : pas d’accès à des fonctions low level. Firefox OS corrige cela.

Et puis si c'était si merdique que ça, est ce que tu crois que Samsung se serait lui aussi lancé dans la course avec Tizen, et la sortie très prochaine de nouveaux téléphones tizen ?

Ca montre plus un mode panique (faut voir le statut de l'API FFOS dès qu'on sort d'un bête navigateur web et qu'on veut toucher au matos) qu'une grande réfléxion.

mode panique ? Non, mode de développement itératif. API pas stable, c'est normal, c'est le début. tu devrais comprendre, tu développe non ? C'est d'ailleurs pour cela que beaucoup ne sont utilisables qu'en mode privilegié ou même certifié : pour pas que tout le monde s'amuse à les utiliser tant que ce n'est pas stable et standardisé (bon, y en a qui resteront en mode certifié ou privilégié, pour des raisons de sécurité).

Je ne sais pas si tu as remarqué, mais c'est comme ça que se développe le web depuis 20 ans. On peut ne pas aimer ce mode de dev (ça a des inconvénients), mais le fait est que ça fonctionne quand même (parce qu'il y a aussi beaucoup d'avantages).

J'ai pourtant essayé, mais rien à faire, sorti du web, creve

Oui, c'est l'originalité du truc. Et comme on en a déjà discuté, ça répond déjà à énormément de besoin. Si tu veux faire des trucs originaux avec des programmes compilés et autres, oui , ce n'est pas pour toi. Tu n'es pas la cible. Point.

Maintenant, un constructeur peut très bien installer FirefoxOS, avec les programmes (ou plutôt lib) "natifs" qu'il veut, et exposer des API en JS pour les utiliser dans des applis web. Mozilla le fait depuis plus de 15 ans ce genre de choses.

Pour rappel, une fois on a discuté du refus de Mozilla d'accepter H264, j'avais parié un changement sous 2 ans, Mozilla a tenu dans sa bétise que pendant 6 mois, et aujourd'hui il vont même mettre des DRM dans Firefox (en option).
Faut croire que je n'ai pas toujours tort dans mes critiques de Mozilla…

Tu oublie de dire que ces problèmes sont liés à des forces extérieures à Mozilla. Mozilla n'a aucun contrôle sur H264 ou les DRM.
Et puis peut-être que le résultat aurait été autre si Google avait mis plus de moyens et de lobbying sur ses codex vpX (supporté par Mozilla). Donc on voit bien ici que Mozilla ne pouvait pas faire grand chose au final.

Alors que sur le développement de FirefoxOS, elle a tout contrôle (modulo les exigences des constructeurs/opérateurs au niveau des certifications logicielles/hardware). Faire Firefox OS ne va pas lui faire perdre des parts de marché (au contraire). Alors que ne pas supporter H264, si. Les enjeux, les pressions, les finalités ne sont pas du tout les mêmes. Ne compare pas choux et carottes.

j'ai aussi dit que XUL n'avait pas vraiment d'avenir, je me suis fait insulté comme quoi c'était l'avenir qui allait tout déchirer… Mais bon, la réalité est arrivée après une grosse pub "ça va tout déchirer" hop Mozilla a dit merde à ceux qui y ont cru et a tout laché

Et ? la réalité n'est pas celle qu'on pouvait espérer, certes, (pas de "produit marketisé" XulRunner), mais la techno est toujours là :

• l'interface de Firefox est toujours en XUL, les extensions sont en XUL pour la plupart
• La plupart des concepts apportés par XUL (modèle de boite spécifique en CSS, flexbox et les composants graphiques XBL pour ne parler qu'eux), sont en passe d'être standardisés (respectivement dans CSS3, et les web components).
• Si par "XUL", on entend la plateforme Mozilla (avec donc XPCOM, Gecko, XulRunner et cie), bah, c'est toujours là aussi pour ceux qui veulent faire des navigateurs (ou autres types d'applis mais je ne le conseil plus trop, le HTML d'aujourd'hui permet de faire beaucoup par rapport à l'époque de l'engouement XUL). XulRunner est toujours buildé et dispo sur le ftp. Firefox peut toujours lancer des applis xul (firefox --app). Et cette plateforme sert encore pour… FirefoxOS (même si le langage XUL n'est pas utilisé).

Bref, XUL va mourir dans quelques années (quand Servo aura pris la relève, peut-être), mais il aura laissé un héritage. Il aura servi de laboratoire pour HTML5++.

Je parie donc : dnas 5 ans, il n'y aura plus de smartphone FFOS en vente.

5 ans, c'est énorme à l’échelle de l'informatique. Tu ne te mouilles pas trop :-). Si ça se trouve, dans 5 ans, y aura plus non plus d'android vendu, supplanté par un nouveau système à la mode pondu par une de ces grosses boites (Samsung avec Tizen 12.0 par exemple ? :-D ). Et puis au final, tu as une chance sur 2 de gagner ou perdre. C'est pas un pari risqué :-)

Encore une fois, les batailles perdues par Mozilla (H264, DRM et autre) ne sont pas du tout sur la même problématique que celle sur le mobile. Il me semble bien plus difficile de prédire l'avenir de FirefoxOS que celle du support de H264. D'autant plus que Mozilla ne se lance pas dans une bataille frontale avec les gros du secteur, en visant les marchés émergents.

Mais bon, peut-être que dans 5 ans tu auras raison. La vie d'un logiciel ou d'un système tient à tellement de paramètres. Peut-être aussi que FirefoxOS aura muté en autre chose (tout comme les concepts de XUL, fusionnés dans HTML5/CSS en amélioré). Qui c'est ?

Une chose est sûr, FirefoxOS aura fait avancé le schmilblick, ne serait-ce qu'au niveau de Firefox. Les avancés en terme de perfs, d'API web etc aura fait progressé Firefox et HTML ;-)
```

ne permet pas de naviguer en mode privé

ça viendra je pense. Dans la version 1.3 que j'ai, on peut déjà paramétrer le doNotTrack.

M'enfin la navigation en mode privé est une chose plutôt complexe à mettre en oeuvre. ça demande du boulot compte tenu la nature de l'appli navigateur. voir réponse suivante :

aucune extension n'est utilisable

Ça c'est normal. Le navigateur dans FirefoxOS n'est qu'une "bête" appli HTML, alors que Firefox et Firefox Android sont un peu plus que ça ;-)

Mais nul doute que ça va s'améliorer, une fois que certaines API internes seront exposées à cette appli html via JS…

Terminal / shell (et qu'est-ce que dit ls -la /) ?

Oui, tout à fait possible, en utilisant l'utilitaire adb que tout développeur android connait. Tu branches ton mobile, adb shell et voilà, un ls -la ça donne un truc dans le genre (ici sur mon Keon)

drwxr-xr-x root     root              2014-06-17 17:23 acct
drwxrwx--- system   cache             2014-04-10 23:04 cache
-rwxr-x--- root     root       190764 1970-01-01 01:00 charger
dr-x------ root     root              2014-06-17 17:23 config
lrwxrwxrwx root     root              2014-06-17 17:23 d -> /sys/kernel/debug
drwxrwx--x system   system            2014-03-13 15:43 data
-rw-r--r-- root     root          147 1970-01-01 01:00 default.prop
drwxr-xr-x root     root              2014-06-17 17:23 dev
lrwxrwxrwx root     root              2014-06-17 17:23 emmc -> /mnt/emmc
lrwxrwxrwx root     root              2014-06-17 17:23 etc -> /system/etc
-rwxr-x--- root     root       182036 1970-01-01 01:00 init
-rwxr-x--- root     root          866 1970-01-01 01:00 init.b2g.rc
-rwxr-x--- root     root         2344 1970-01-01 01:00 init.goldfish.rc
-rwxr-x--- root     root         8772 1970-01-01 01:00 init.qcom.class_core.sh
-rwxr-x--- root     root         4529 1970-01-01 01:00 init.qcom.class_main.sh
-rwxr-x--- root     root        16868 1970-01-01 01:00 init.qcom.rc
-rwxr-x--- root     root         4570 1970-01-01 01:00 init.qcom.sh
-rwxr-x--- root     root        27797 1970-01-01 01:00 init.qcom.usb.rc
-rwxr-x--- root     root         5096 1970-01-01 01:00 init.qcom.usb.sh
-rwxr-x--- root     root        21715 1970-01-01 01:00 init.rc
-rwxr-x--- root     root         2348 1970-01-01 01:00 init.target.rc
drwxrwxr-x root     system            2014-06-17 17:23 mnt
drwxrwx--x system   system            1980-01-06 01:11 persist
dr-xr-xr-x root     root              1970-01-01 01:00 proc
drwxr-xr-x root     root              1970-01-01 01:00 res
drwx------ root     root              2014-04-09 00:45 root
drwxr-x--- root     root              1970-01-01 01:00 sbin
lrwxrwxrwx root     root              2014-06-17 17:23 sdcard -> /mnt/sdcard
drwxr-xr-x root     root              2014-06-17 17:23 sys
drwxr-xr-x root     root              1970-01-01 01:00 system
-rw-r--r-- root     root          272 1970-01-01 01:00 ueventd.goldfish.rc
-rw-r--r-- root     root         9610 1970-01-01 01:00 ueventd.rc
lrwxrwxrwx root     root              2014-06-17 17:23 vendor -> /system/vendor

Serveur SSH ?

Jamais essayé, mais c'est du linux, donc peut-être. Après faut voir ce qui est possible de faire au niveau config réseau etc… Y a peut-être des choses bridés, je ne sais pas. Je m'y connais pas assez en système embarqué téléphonique.

Mais bon, l’accès au shell et la possibilité d'activer l'USB media storage devrait être suffisant pour bidouiller son téléphone.

Fonction hotspot Wifi ?

Oui, c'est de base dans Firefox OS

Pour ce genre de besoin, pas la peine de repartir de zéro et donc avoir des années de retard, on peut prendre le code source d'Android, le recompiler, et remplacer les logiciels proprio par des versions libres dans le package, plutôt que d'essayer de tout mettre en HTML/JS.

Mais oui, bien sûr. C'est si simple ! Pourquoi n'y ont-ils pas pensé ??!!

Des fois, je me demande si tu le fais pas exprès de faire du FUD et de faire des réponses connes.

Alors, réfléchissons ensemble sur le pourquoi Mozilla n'est pas reparti sur une base Android.

1) Quel serait l’intérêt pour Mozilla de faire un OS à base d'Android ?

Je n'en vois aucun (mais tu vas peut-être m'aider). Des OS basé sur Android, y en a à la pelle. Au niveau concurrence, c'est mortel. Ça serait vraiment difficile d'apporter une plus-value. À part effectivement supprimer les cochonneries de l'OS, et y installer d'office Firefox Android… Aucune réèlle innovation.

2) Qui voudra installer un OS pareil ? Quel constructeur voudrait installer un OS pareil sur ses téléphones ?

Grande question. Personne je pense, puisqu’aucun intérêt par rapport à la concurrence. Et puis il me semble que de telle distribution OS Android 100% libres existent déjà…

3) Mozilla peuvent-ils faire un OS basé sur Android ?

Je ne sais pas si tu as remarqué, mais chez Mozilla, ils n'ont pas beaucoup de compétences en Java. Ils savent faire du web (très beaucoup, l'interface de Firefox, c'est fait avec des technos du web), du C++ (beaucoup), du python (beaucoup, pour leurs applis et sites web) et plein d'autres technos. Mais peu de Java. Ah si, il y a la version Android de Firefox. Mais faire un OS plutôt qu'une appli, c'est une autre paire de manche. Il faudra beaucoup plus que quelques gus javaiste dans un garage. Bref, il va falloir investir dans des ressources humaines.

Enfin bref, tout ça pour dire que reprendre un existant Android, très peu d'intérêt pour Mozilla.

Alors que réaliser un OS dont toutes les applis sont faites avec les technos du web, c'est beaucoup plus intéressant de leur point de vue :

• ils connaissent à fond la techno (le savais-tu ?)
• ils ont plein de développeurs sous la main connaissant la techno.
• ils ont même déjà la base du système ! Eh oui,
  • ils ont un moteur web (si si, Gecko, qui est utilisé par Firefox).
  • Y a un petit autre projet qui fourni un kernel, linusque je crois. Non, linux.
  • Suffit ensuite de lancer un Gecko au démarrage + une appli web (le bureau), et c'est plié. En tout cas, pour le Proof of Concept, ça a pris très peu de temps à le faire.
• Et pour les applis ? Genre pour passer un coup de téléphone ? Envoyer des SMS. Certes, il va falloir les développer, ajouter des API en Javascript pour manipuler le hardware (lancer les appels, envoyer/recevoir des sms …). Et pour les autres types d'applis, y a qu'à se servir. Le web en est truffé. Et puis ajouter une API JS dans Gecko, c'est pas la mère à boire si il y a les libs systèmes qui vont bien. Oh, surprise, y a déjà un système qui a une base pour ça… Comment s'appelle-t-il déjà. Ah oui, Android. Reprenons les libs systèmes d'android pour démarrer le projet, ça ira (mais on enlève java, faut pas déconner non plus). Bref, CONTRAIREMENT À CE QUE TU VEUX FAIRE CROIRE, NON, MOZILLA N'EST PAS PARTI DE RIEN. Ils n'ont pas réinventé la roue. Ils ont adapté des composants existants, les ont assemblés, et voilà, ça donne Firefox OS.

Intéressant aussi pour Mozilla car :

• Le fait que tout soit en HTML/JS sur un téléphone, c'est assez innovant, il faut le reconnaitre : pas d'autres téléphones de ce type chez la concurrence. À l'époque, il y avait bien des projets en gestation, comme Tizen, (Webos ?), mais rien de concret sur le marché à grande échelle (ou en tout cas, ça reste embryonnaire)
• Tout en HTML/JS : ça veut dire, dès le départ, des milliers (millions?) d'applis disponibles : suffit de surfer sur le web.
• Autre innovation sur le téléphone : ce n'est pas une nième nouvelle techno à apprendre : tout développeur web qui se respecte peut adapter son appli pour FirefoxOS. Très simplement (un peu de responsive design, un fichier manifest…). Et si ils font leur applis pour Firefox OS, ils pourront aussi la réutiliser pour les autres OS.
• Le coût d'investissement du départ est faible : ils ont tout sous la main pour prototyper, et ensuite aller toquer chez les constructeurs et opérateurs pour voir si ça les intéresse.
• Nouveau type d'OS : il y a des chances justement que ça les intéresse. Ça permet de se démarquer de la concurrence (où tout est Android).
• L'OS peut fonctionner sans problème sur des téléphones low-cost (contrairement à Android qui nécessite des machines avec un minimum de puissance, même si ils ont fait des progrés c'est vrai) : idéal alors pour se lancer sur des marchés émergeants où les smartphones sont quasi inexistants, car les stars comme Samsung ou Apple, sont beaucoup trop couteux. Et ça tombe bien, ces marchés sont nombreux.

Résultat aujourd'hui :

• Des dizaines d’opérateurs et constructeurs se lancent dans l'aventure (donc oui, Mozilla a la taille de faire un "petit" OS et d'attirer les entreprises)
• Il n'y a pas que sur les téléphones. Par exemple des gros constructeurs (comme LG) se lancent dans les TV connectées à base de FirefoxOS, dans les tablettes (les premières tablettes sont arrivées ce moi-ci chez les contributeurs mozilliens).

Bref, pour le moment, je ne sais pas ce qui te fait dire que Mozilla "n'arrive pas à rendre l'OS assez sexy pour attirer d'autres entreprises", mais ce que je vois pour le moment, c'est tout le contraire. Sans pour autant affirmer qu'un jour Mozilla détrônera Samsung ou Apple. C'est pas l'objectif d'ailleurs : comme d'habitude, c'est proposer du choix.

Alors oui, des fabricants peuvent ne pas proposer des mises à jour.
Tout d'abord, on notera que ce n'est pas la faute à Mozilla.
Ensuite : ok ça peut compliquer le développement, mais la plateforme Firefox OS a des avantages pour diminuer ces inconvénients

• les applis Firefox OS, c'est du web. Si ton appli n'utilises pas (trop) de fonctions propres au mobile, tu peux tout à fait tester dans un firefox sur ton desktop/laptop. Il suffit de savoir que telle version de Firefox OS correspond à telle version de firefox, et donc d'avoir lesdits versions de Firefox installées.
• Firefox comprend un émulateur (via une extension) et un environnement de développement pour Firefox OS, qui facilite entre autres choses :
  • le test de l'appli sur sa machine dans l'emulateur
  • la mise à jour vers un téléphone
• Le téléphone officiel de Mozilla, le Flame, a des fonctionnalités sympa : on peut brider la mémoire par exemple, la taille de l’écran il me semble, etc. Ceci pour exécuter l'OS dans un environnement similaire à tel ou tel autre téléphone.

Enfin, les developpeurs d'appli Firefox OS sont en principe des développeurs web, et ils ont l'habitude d'avoir à tester leur appli dans une multitude de navigateurs, donc ça ne devrait pas trop les déranger même si il est vrai c'est un peu plus lourd avec des téléphones.

Pour les versions instables, c'est pareil, après avoir installé une première à la main. Les suivantes se mettent à jour (automatiquement ou en confirmant).

on auto-finance le libre

Si tu as des pistes sérieuses pour le faire (je veux dire, pas pour payer 4 gus dans un garage, mais permettre de payer des centaines de dev à temps plein), fait nous partager ça. Mozilla, la fondation linux et autres seraient très intéressé je pense.

Un logiciel ne nous plaît pas, on s'en inspire et on "fait un autre". Un logiciel dérive privateur, on le fork et on garde ce qui est bien.

Bon courage pour forker Firefox !!

Ce que tu n'as apparemment pas conscience, c'est que le libre n'a pas seulement besoin de développeurs pour exister, mais surtout d'utilisateurs.

Et ce n'est pas en proposant à madame michu de mettre les mains dans le cambouis pour modifier le firmware de son ordinateur sans que finalement, elle y trouve un intérêt concret pour elle, ou en lui interdisant de regarder la majorité des vidéos existantes, ou en lui interdisant de pouvoir échanger des fichiers avec tonton jean qui est sous windows, que tu vas l'inciter à utiliser du libre.

Et ce n'est certainement pas en proposant aux entreprises du "freebsd sans x264, samba etc" que tu vas les inciter à utiliser du libre. Au mieux, elles vont te faire "lol". Car vois-tu, une entreprise fait bien souvent dans le pragmatisme : elle choisie un outil pour atteindre ses objectifs, pas pour faire plaisir aux libristes intégristes. Si l'outil l'empêche de réaliser ce dont elle a besoin (ex: pas de Samba, donc pas d'intégration dans un réseau windows), elle ne l'utilisera pas, qu'il soit libre ou pas.

Bref, si du "freebsd sans x264, samba etc.", c'était si génial, sa part de marché serait beaucoup plus que 0,0001%. Et ce n'est pas avec 0,0001% de parts de marché que tu attire les développeurs (qui sont avant tout des utilisateurs).

En conclusion : pour qu'un produit existe, il faut des utilisateurs, donc faut que il réponde à un besoin, et qu'il soit sexy. Désolé de te le dire, mais du "freebsd sans x264, samba etc.", personnellement, ça ne me fait pas bander du tout. J'ai un taf, j'ai besoin d'avoir des outils qui fonctionnent (et pas passer des heures à tenter de faire fonctionner des trucs libres innachevés). Et donc voilà, depuis 2001 que j'utilise linux (que ce soit sur les bécanes perso ou pro), j'ai aussi des blobs binaires proprio comme les drivers amd ou nvidia, des trucs qui discutent avec la concurrence (samba etc..), et un bios proprio parce que franchement, jusqu'à maintenant, je ne vois pas l’Intérêt d'avoir un boot libre (sachant que la plupart du temps, toutes les merdes de TPM, de vérifications dans UEFI et consort, c'est désactivable).

On s'en tape que Firefox soit utilisé par 100 000 ou 1 000 000 personnes, on auto-finance le libre, on le développe et on le maintient.

Ah non, on ne s'en tape pas. Gecko, le moteur de Firefox, serait au niveau de KHTML si il n'était pas utilisé par des millions de personnes. En effet, si il n'était utilisé que par 1 000 000 de personnes :

• Mozilla gagnerai très peu d'argent avec son contrat avec Google ou autre moteur de recherche (rappel : Google paye Mozilla en échange du trafic que Firefox apporte grâce à son fonction de recherche utilisant Google)
• On peut même dire qu'il n'y aurait pas de contrat avec Google (1 million de user, c'est ridicule pour Google, donc n'y verrait pas trop d’intérêt, ou en tout cas, les termes du contrat serait tout autre car Google serait alors en position de force)
• pas d'argent, pas de développeurs payés à temps plein (et il y en a actuellement plusieurs centaines)
• pas d'argent, pas de R&D sur d'autres projets (ex: Rust, ou Servo, un moteur web à l'architecture innovante)
• pas d'argent, peu de participations au W3C, peu de combats pour le libre, peu d'influence à l'encontre de ces merdes de DRM, sur les codec bardés de brevets etc.. Même si ce sont des batailles de perdues, ça a fait prendre conscience au moins à certaines personnes de l'importance d'avoir du libre
• Et donc, si pas de développeurs payés à temps plein, pas d'avancée rapide sur le navigateur, malgré les centaines de contributeurs bénévoles (la complexité d'un moteur web nécessite des développeurs expérimentés à temps plein, c'est un fait).

Et ce ne sont pas avec les quelques milliers de dollars de dons que Mozilla recoit, qu'elle pourrait financer les développements nécessaires pour être dans la "compétition". Peut-être que Mozilla pourrait avoir plus de participations de la part de sociétés (des développeurs payés à temps plein par des boites), comme ça peut être le cas pour le noyau linux ou autre, mais encore faut-il que celles-ci y trouvent de l'intérêt ("pourquoi s’embêter alors qu'il y a IE ou webkit").

C'est aussi pour ça que j'attends beaucoup de sqlite4. Il permettra de faire assez simplement le lien entre SQLite et les mécanismes qui permettent de stocker des données sur le disque en JavaScript, comme localStorage.

Oui, donc en utilisant IndexedDb ou localStorage comme backend. Et le saviez-tu ? L'implementation de localStorage et IndexedDb dans les navigateurs (en tout cas dans Firefox), repose sur… SQLite (natif).

En résumé : une implémentation de SQLite4 en javascript qui utilise IndexedDb qui utilise SQLite.

Bref, pour les pages web : strictement aucun intérêt. Autant utiliser directement IndexedDb. Sauf à proposer un interpréteur SQL par dessus IndexedDb. Mais je doute que porter SQLite4 reste d'un grand intérêt : il n'y a pas besoin de tout le code de SQLite4 (converti donc en asm.js) pour avoir au final qu'un interpreteur SQL.

Bientôt, on va voir arriver une implémentation de Redis JS qui repose sur l'implémentation JS de sqlite4 qui repose sur IndexedDb qui repose sur un sqlite natif…

Rien ne va plus pour les libs SSL en ce moment

certainement dû au fait que plusieurs personnes inspectent le code, depuis l'affaire Heartbleed, depuis donc qu'on a pris conscience que peu de monde y contribuait.

À mon avis, ce n'est que le début des découvertes…

il est chiant cet homme du milieu. J'ai remarqué qu'il revenait souvent mettre son bazar. Faudrait vraiment que la police fasse quelque chose. On sait qui c'est au moins ?

Si tu ne trouves pas preneur, tu peux y déposer tes écrans dans toutes bonnes déchetteries. Il y a des paniers/bennes/containeurs spéciaux pour ça. Ils seront à priori recyclé. ou pas. Peut être envoyé en Afrique via des filières mafieuses ou autre, mais bon, ce n'est pas vraiment possible de vérifier, tout comme ce que fait ecosystème des déchets. Maintenant, je fais plutôt confiance à ma dechetterie ou eco-système. Car si on doute de ces trucs, on fini par plus rien faire et à entasser chez soi (ce qui n'est pas forcément la bonne solution non plus).

J'ai du mal à voir ce que cela apporte de plus par rapport à Seafile

pour le moment PhantomJS me parait plus intéressant notamment parce qu'il est headless

Oui mais il a un super vieux moteur webkit. Et la version 2, qui devrait utiliser un webkit récent, se fait attendre depuis longtemps…