Zenitram a écrit 29583 commentaires

Reste à voir si c'est ça qui va motiver assez les dév de toucher à la carrosserie de la machine des utilisateurs (car modifier le code de Firefox OS des utilisateurs, je n'y crois pas ;-) ) en échange de ne pas pouvoir toucher le moteur. N'oublions pas que ce qui intéresse en priorité les développeurs mobiles, c'est l'utilisateur, pas l'OS chez lui (comme pour Linux).
L'avenir nous le dira.

emscripten n'est qu'un outil, c'est pas magique

Je répondais à djano qui laissait croire le contraire.

Evidemment, toutes les interactions sont à refaire, je ne vois pas où est le problème là-dedans,

Le problème est quand on balance aux dev un "c'est simple, tu compiles et lances". C'est faux, il y a les interactions à refaire, et d'autres choses.
Faudrait un peu que les fanboys de telle ou telle technologie arrêtent de vendre des technos pour ce qu'elles ne sont pas.
Par exemple, Qt a pour but d'avoir le même code partout (tu compiles et lance, c'est Qt qui s'occupe des interactions), emscript pas du tout (pour le moment) : il ne fait que compiler, charge au dev de faire les interactions.

---

Sinon, c'est une très bonne initiative (et assez primordiale pour Firefox OS : Android à bien un NDK pour le code C/C++… Sans ça, c'est se couper d'une bonne partie d'apps.)

Ah bon? Renseigne toi avant: http://www.unrealengine.com/html5/

Ah bon? Renseigne toi avant : J'ouvre FF23 (clean, je ne l'utilise que pour des tests), il bloque à "Downloading data" à 100% et consomme 900 Mo de RAM. Ah, après 5 bonne minutes (j'ai une connexion à 50 Mbps quand même…) ça passe à un truc! Super, j'ai 2 images par seconde (et je reste en petit fenêtré…) alors que je peux jouer en natif à bien plus que ça. Je me barre.
Bilan : merci pour la démo, ça démontre bien.

Ca c'est fait, grace a des telephones annonces vendus bien moins chers.

Un téléphone Android, c'est moins de 70€ en France. A combien sera/est un téléphone Firefox OS? Cette différence sera-t-elle suffisante pour vendre?
Sinon, pas cher n'est pas tout, on peut défendre très bas quand on vire des fonctionnalités, pour vendre un truc pas cher il faut quand même des fonctionnalités. Qu'apporte FFOS de ce côté pour attirer?

Tu prends une appli native, tu la passes dans ecmascripten et tu obtiens une belle appli deployable et utilisable sur le web, donc aussi dans Firefox OS.

Essaye cette démo et dis-moi comment tu fais pour éditer un fichier qui est dans ton home (un peu la base de certains logiciels).
Désolé, ce n'est pas simple, toute la partie interaction est à refaire si tu veux un truc utilisable et non juste une démo "coucou je sais compiler" (sans compter qu'un simple éditeur de texte rame de chez rame sur une machine puissante)

Faudra arrêter un jour de prendre les gens pour des idiots en leur vendant un truc qui lave gris (qui est mieux que noir, clairement) comme plus blanc que blanc.

ecmascripten

C'est emscripten

tu la passes dans (…)

Essai : après bidouille (il y a quand même des changements à faire dès que tu veux interagir un peu avec l’environnement), lancement d'un simple logiciel, monte à 1 Go de RAM et crash. Euh…
Non, désolé, ce n'est pas aussi simple que tu le laisses entendre.
(ça ne veut pas dire que que c'est pas une bonne idée, il y a du potentiel, mais c'est encore à un stade qui permette de dire "Tu prends une appli native, tu la passes dans ecmascripten et tu obtiens une belle appli deployable et utilisable sur le web". Ca dépend)

Je ne comprend pas la différence que tu fais entre H264 et WebM alors. Tu seras un utilisateur heureux de H264 qui n'a aucun problème de ton point de vue.
Filtre sélectif?

Rigolo.

Les libristes utilisent webm

question idiote : pourquoi webm par rapport à x264 pour des libristes? J'ai du mal à voir le gain libriste, vu que les deux sont soumis à brevets (C'est google qui le dit).
La seule différence est le prix (0 pour l'un, ce qui il faut le reconnaître le transforme en "format ouvert", pas libre mais ouvert c'est déjà ça), mais ça ne le rend pas plus libre (juste gratuit), donc un libriste qui refuse H.26 mais aime WebM me fait doucement rigoler… Il est juste proche de ses sous, rien à voir avec le libre.

sacrés "libristes" (oui, entre guillemets).

Edit : argh, grillé.

va principalement choqué les plus sensibles. (etc)

Qu'est-ce qu'il ne faut pas balancer pour juste parler d'un problème pratique pour les vendeurs…
Effectivement, ça faisait longtemps qu'on n'avais pas eu le sujet sur le table mais on se marre toujours autant quand il revient.

Les libristes utilisent webm et theora.

Quels salauds de non libristes de développeurs de x264, ffmpeg, VLC, mplayer… Et maintenant Mozilla ("obligé" n'est pas une excuse, on a toujours le choix). Merci de ne pas généraliser le comportement de certaines personnes à quelque chose qui n'a pas grand chose à voir.

WebM c'est une solution technologique pas a la hauteur face a son concurrent, sur un marché déjà pris. Aucun rapport.

Tiens, remplace WebM par Firefox OS, la phrase marche super bien (oui, le marché est déjà pris).
non, parce qu'à sa sortie, WebM c'était quand même "le mega truc qui déchire sa race contre le concurrent" (tm) et était largement soutenu par les libristes qui le voyaient comme un truc super… Bon, avant, ils s'étaient émerveillés aussi devant Theora (la, ça en était ridicule).
L'histoire est un éternel recommencement du "aucun rapport"…

en étant bien préparé (comme le fait aujourd'hui FFOS)

tu plaisantes la?

Mozilla le sait et veut que les développeurs adoptent leur solution pour avoir plein d'application rapidement.

Il veut, OK. Reste à voir si les développent acceptent.
Vu la réaction des devs ici et ailleurs, j'ai un doute.

Rendez-vous dans 3 ans pour le bilan.

Google avait une super-méga-liste de partenaires lors de la sortie de WebM, ce qui ne l'a pas empêché de se rétamer en beauté.
Il faut plus qu'une liste, il faut un engagement financier. Il faut voir ce qu'a coûté les développements de chaque entreprise pour avoir un truc compatible (c'est du web, donc bon, on met 2-3 goodies pour FFOS et sinon on reprend l'interface web avec ses limitations? Ou est-ce qu'il y a une appli super-bien intégrée à l'OS?)

encore faut il atteindre la masse critique nécessaire a sa survie.

Exactement, et entre les utilisateurs passifs qui ne voient pas de limitations avec Android et les utilisateurs actifs à qui ont dit qu'en fait ce n'est pas pour eux et que si ils insistent on leur file une API complexe, bravo si cette masse critique est atteinte.

C'était le même argument "avant" pour les ordiphones (un téléphone c'est fait pour téléphoner, point, le web ça consomme trop), au final on a préféré perdre pas mal d'autonomie et avoir deux en un.

On peut très bien faire les deux en un, possibilités :
- avoir un GPU qui sait s'adapter en conso (de quasi rien à beaucoup pour la puissance)
- double GPU, le puissant est étaient (conso 0) si pas de jeu en cours
Les deux méthodes sont déjà employées dans d'autres produits.

Les consoles de jeu portables et les ordiphones ont beaucoup à voir, d'ailleurs il faut voir le nombre d'ordiphones utilisés comme console de jeu portable dans le train de nos jours.
Les consoles de jeu portables sans partie téléphoniques sont vouées à ne plus faire beaucoup de ventes, remplacés par les ordiphones comme les baladeurs audio ont beaucoup été remplacés par l'ordiphone avant.
(il parait même qu'il y a un projet dans les cartons d'ajouter une manette au prochain iPhone).

j'ai juste énoncé un fait

Ok… Je le connais toutefois, sinon je n'aurai pas écrit ce que j'ai écrit au début.

parce que les sacs ça a souvent deux-trois poches avec du bordel dedans,

Tu as souvent un sac avec 2-3 poches quand tu vas faire tes courses? Quelle durée du contrôle? J'avoue ne pas voir le problème. En fait, je ne sais pas, ça doit être automatique, quand j'ai un sac je l'ouvre et le présente en même temps que "bonjour".

Et je comprends pas ce que tu veux dire avec la politesse

C'est peut-être subjectif, mais j'estime que la moindre des politesses quand on va dans un magasin avec un sac à dos est présenter son sac à la sortie. Bien plus important qu'un bonjour/au revoir vis à vis des gens en face, et surtout : ça ne coûte rien (et certainement pas un truc "vie privée" ou "ne pas faire comme tout le monde") et c'est 100% compréhensible qu'on le demande.

Bref, je disais juste que ça faisait longtemps que quelqu'un n'avais pas sorti une complainte sur l'horreur imaginaire que c'est, c'est tout :).

C'est vrai que dans les depots debian et ubuntu tu as plein d'applis dédiés smartphone !

Ce n'est pas le sujet.
Il est juste dis que rien n'est nouveau, qu'il y avait déjà les outils, et que donc on constate juste une chose : une API en plus de ce qui existe déjà, et pas la plus facile.

Donc oui, un emacs codé en html5 a la sauce firefox OS, ca pourrait etre interessant pour les devs et par conséquence pour les utilisateurs.

Juste que pour le moment un package FFOS est aussi universel qu'un .deb (oui, pas du tout universel), qu'il y a une une tentative de standardisation (LSB) mais que pas foule n'a accepté de suivre et que toutes les tentatives d'avoir un format "portable" (autopackage…) se sont ramassées.
Je prédis le même sort à cette "tentative de standard fait tout seul dans son coin"… Pour les mêmes raisons.

Les devs ont pour le moment tout simplement un langage (ben oui, il y a des choses pas en HTML5… Bon, parait qu'il y a asm.js maintenant donc bientôt un port HTML5 d'emacs?) en plus, un format de package et une API en plus, sans savoir si quelqu'un d'autre compte l'utiliser. quand aux utilisateurs, ils seront limités par ce que peuvent faire les devs (soit pas grand chose sorti d'un client web passif, genre ChromeOS, avec le succès qu'on lui connait malgré le rouleau compresseur Google. Sachant que l'idée de google est de tout amener à lui sur ses serveurs… Bonjour la liberté proposée par Firefox OS).

Quand on creuse un peu, ça fait une sacré différence par rapport à la pub… On verra donc bien si les devs en question se laissent tentés par ce produit assez fermé, le temps sera l'arbitre.

Wow… je ne vois pas le rapport d'ouvrir son sac pour un contrôle rapide utile et la pression sociale, mais bon… il faut toujours trouver une "bonne raison" même si HS.

Merci pour la démonstration : c'est bien ce genre de réaction ("vous n'avez pas le droit" wow…) qui me fait un bon délire (tu as bien noté que je n'ai pas dit que c'était illégal de refuser?)
Voila, je n'avais pas vu passer la chose ici depuis un moment, c'est de retour.

Je ne suis pas non plus obligé de dire bonjour, mais je le fais. Ca ne te dérangera pas, suivant ce que tu dis, si pour tout ce qui est pas obligatoire, je te dise "j'ai le droit de te dire connard" et j'en passe. Bref, la politesse ça se perd…

avec le firefox official kivabien ca tourne très très bien

C'est cool de me retrouver comme il y a 10 ans niveau détails graphiques alors que j'ai une machine ultra-puissante par rapport il y a 10 ans. Quand aux 25 fps, il faut faire du "low res" sinon il n'y a pas, mais vraiment pas (testé avec FF23).
Sans parler que ça faisait très très longtemps que je n'avais pas eu l'histoire du clavier non américain (penser à la lettre "A"…) dont la position physique pour bouger est n'importe quoi.

C'est sensé impressionner?
Alors oui, c'est plus facilement "installable" (on y joue direct), mais on reste assez loin de 2013 quand même. Après, certes, les casual gamers se foutent du graphisme (mais bon, ma PS4 et Xbox One vont se vendre aussi).

Relis : je dis la même chose ;-).
J'ai bien dis que ce que je décrivais en premier était si j'étais comme lui. Si je dois choisir, la balance penchera en faveur du concurrent (mais il faudra que je me renseigne de sa façon de voir aussi pour l'égalité) seulement si j'ai 2 produits avec le même "score" de fonctionnalités, pas en élément bloquant comme il l'a fait (le code est la priorité, et c'est libre, je peux forker si il fait des conneries dans le futur). Mais SQLite a plutôt l'air d'avoir pas de concurrent du même niveau.

Merci.
J'avais regardé comme un idiot "File API" mais pour travailler avec un fichier du coup il faut pas de "File API" (ah…) mais une autre API (implémentée que dans un navigateur, donc code spécifique comme les autres OS mobiles contrairement à la pub, ou alors j'ai loupé la partie où si on a Firefox sur n'importe quel OS mobile, on peut utiliser le même code sans problème) et un IndexedDB que je ne comprend pas ("MyDatabase" sort d'où? La demande est d'écrire sur la carte SD, dans un fichier qui pourra être lu par n'importe quelle application du même style, genre je sauvegarde une photo et l'application d'affichage d'image pourra afficher cette photo, bref un truc de base)

En tous cas, on n'a pas la même définition de "immensément simple"… Ni la même définition de "lancer un produit" (toutes les API citées, qui sont des API d'OS de base, sont en "expérimental", "need review"… Quand les autres lancent un produit, l'API est dite stable, pour que le codeur ne doive pas changer le lendemain)

On verra bien… après, il y a peut-être un marché pour les navigateurs web avancés sans rien d'autre.

(ah non en fait ça sert à rien d'écrire tout ça j'accède à linuxfr en https…)

Il suffit d'une personne en HTTP et ton HTTPS est "cassé" car la donnée est transmise en clair par un tiers… maillon faible :)

var instanceOfTCPSocket = instanceOfTCPSocket.open(host, port[, options]);

Qui me sera refusé sauf autorisations tout ça, donc même problème que les autres + interface JS chiante et non standard (non réutilisable). Gain pour le développeur?

je suppose que tu parles donc de ton exemple d'ouverture de port.

Je parlais d'un autre exemple mais l'idée est la même.

La différence c'est que tu peux créer toi même ton certificat et approuver toi même une appli non certifié (et en ce qui concerne le dernier point, j'espère que ca sera quand même un peu planqué, parceque sinon ca va être la fête au malware.)

Je peux installer n'importe quelle appli Android sur mon Android, il y a juste une option à activer pour autoriser les apps non signées (j'avoue n'avoir pas encore testé, vu que le store est suffisant pour le moment). désolé, je ne vois pas le gain avec Firefox OS. Gain sur iOS oui, c'est une des raisons d'être d'Android…

---

Désolé, je cherche toujours un gain pour l'utilisateur ou développeur lambda par rapport à l'existant… J'essaye pourtant, mais force est de constater qu'en pratique, on a pas mal de mal à trouver (pr contre, des limitations, ça pas de problème on en trouve). Encore une fois, l'avenir nous dira si j'étais trop pessimiste, je vais m'arrêter la et je re-regarderai dans 1 an peut-être (ou pas si ça fait un bide).

Il y a franchement un problème de com' sur ce qu'apporte Firefox OS par rapport à l'existant et sur ce qu'il n'est pas.

Le truc c'est que dans l'immense majorité des cas tu n'auras pas besoin de créer des sockets.

Dans l'immense majorité des cas Android et même l'iPhone répondent aux besoins des gens n'ayant "besoin de rien d'autre que du basique".
voila, tout est dit, c'est plié.

Et j'ai beau chercher je ne vois pas en quoi il est plus limité que les autres.

Tu dis toi-même que c'est méga-galère. Désolé, mais ça, c'est une énorme limitation. Sans parler du fait que personne n'est encore capable de me montrer comment faire la même chose qu'il y a 40 ans (cf mon autre demande d'exemple Firefox 5).
Sans compter qu'au final, on a une nouvelle API à apprendre, pas adaptée (JS, bonjour…), et on ne voit aucun avantage par rapport à du Android (il faut être certifié etc…). J'ai du mal à voir comment ça peut attirer les développeurs d'un côté et les utilisateurs de l'autre.

Plié 2. C'est bon, je crois avoir mon opinion sur comment ça va finir. Rendez-vous dans 3 ans pour savoir qui sait le mieux anticiper (sachant que je m'étais planté pour H.264 : ils ont lâché encore plus tôt que je ne l'avais imaginé ;-) ).

Non on ne peut pas ouvrir n'importequel socket TCP ou UDP de n'importe quel IP depuis une webapp

OK. Admettons. Mais :
- Qu'on ne nous dise pas "mais si, c'est possible, bla bla bla". Regarde le fil de discussion, la question était très claire, et la réponse était "oui, c'est possible". Il s'avère que les gens ont vérifié et sont un peu énervé qu'on les prennent pour des idiots (AJAX n'est pas sorti hier, on sait ce qu'on peut faire avec, merci).
- webapp ou autre, la n'est pas la question. webapp pas possible, ok. Maintenant, on peut autrement?

J'ai l'impression que Mozilla oublie de dire qu'au final, Firefox OS n'est pas un OS mais un terminal web avancé.
On est loin de la liberté offerte par Android, j'avoue avoir du mal à trouver un intérêt à la chose (Android = qui peut le plus peut le moins)

Maintenant si on parle d'une connection wifi ?ou filaire? ca n'est pas franchement le but de firefox OS, mais c'est possible (meême si franchement j'ai du mal à voir l'interet - à part un proxy en tethering peut-être)

J'ose espérer que l'OS permet le tethering de base. Android et même Windows Mobile le permettent de base. on 'est plus en 2010 mais en 2013.

---

Je vois partout dans les défenseurs de Mozilla OS que Android c'est trop fermé tout ça… Mais au final, désolé, je trouve cet OS vachement limité pour le moment : un peu de joujou avec l'écran, mais à part ça… Quel apport par rapport à Chrome sur Android?

Oui, je cherche encore un intérêt, le truc qui fait préférer Firefox OS aux autres, et pour le moment je vois surtout des limites. Désolé, je n'ai pas compris l'idée derrière cet OS. La communication de Mozilla est auto-destructrice, à laisser croire aux développeurs qu'on peut faire comme sur les autres OS mobiles alors que l'API est très très limitée (aujourd'hui du moins). Je prédis un bon gros retour de flamme.

Une pour créer des sockets coté serveur (en mode listen) et une autre pour créer des sockets coté client (en mode connect).

Désolé de ma stupidité, mais la demande est d'ouvrir un port, de causer avec ce port et c'est tout. Il n'y a pas de serveur dans la demande.

Pour être précis donc, j'ai l'impression qu'on se perd : comment faire

struct sockaddr_in to;
struct hostent *toinfo;
toinfo = gethostbyname(htoname);
to->sin_family = AF_INET;
to->sin_addr.s_addr = *(u_long *)toinfo->h_addr[0];
to->sin_port = htonl(portnum);
connect(s,(struct sockaddr *)&to,sizeof(struct sockaddr_in));
(etc)

en HTML5?
avec htoname = "imap.example.com" et portnum 143. Evidement, seules les communications entre FFOS et imap.example.com et le port 43 (qui parle que IMAP) sont acceptés par le firewall pour le besoin de la démonstration… Reprendre ensuite l'idée avec de l'UDP (c'est utile aussi l'UDP) et IMAP n'ayant été qu'un exemple, il faut pouvoir implémenter n'importe quel futur protocole (client Bittorrent…)

Maintenant de façon assez évidente tu n'utiliseras pas le coté serveur sur un téléphone

Minitel 2? bien sûr que si je souhaiterai aussi pouvoir être serveur. Ce n'est pas une tablette web limitée à quelques interaction avec un écran et une souris qui m’intéresse, mais un smartphone. On parlait pas de liberté? Pour le moment, j'ai l'impression d'avoir nettement moins de liberté qu'avec Android…