Zenitram a écrit 29449 commentaires

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…

Que ce sera immensément simple de coder tes propres application

Je suis preneur d'un exemple en HTML5 "pour Firefox OS" pour écrire ça dans un fichier à ouvrir sur la carte SD par exemple :
http://www.cplusplus.com/reference/cstdio/fseek/

#include <stdio.h>

int main ()
{
  FILE * pFile;
  pFile = fopen ( "example.txt" , "wb" );
  fputs ( "This is an apple." , pFile );
  fseek ( pFile , 9 , SEEK_SET );
  fputs ( " sam" , pFile );
  fclose ( pFile );
  return 0;
}

Ca m'interesse réellement (et espère aussi que je pourrai réutiliser avec firefox normal).
tu dis que c'est immensément simple, j'imagine donc que ça va prendre rien du tout de me démontrer comment remplacer quelque lignes de code C standard très classique et vieux de 40 ans. Je vois à peut près en Java (Android) ou Obj-C (iPhone), mais en HTML5…

Les 8 000 000 de développeurs HTML5

t'es au courant que dans les dév' HTML5, il y a des dev PHP, Java… Pour la partie "intelligente"? En app "FFOS", il faut donc tout recoder cette partie. Et pour le matos, c'est tout à apprendre (nouvelle API). Il reste la partie présentation certes… Comme pour les autres OS qui permettent d'utiliser le client HTML5 aussi.

Il y a quelqu'un pour croire sérieusement que c'est une "killer feature"? J'espère qu'il y a d'autres choses sous le capot pour attirer et les développeurs, et les utilisateurs (en dehors des libristes détesteurs d'Android, ce qui n'est pas classique).

Mais si je veux me connecter à autre chose que de l'IMAP (par exemple une version subtilement différente, ou qui utilise un mécanisme d'authentification non-standard), je vais me faire voir.

J'ai l'impression qu'on essaye de nous faire prendre des vessies pour des lanternes…
Bon, il y a quelqu'un qui peut répondre clairement à cette question : avons-nous accès aux sockets de cette machine (pas d'une autre), oui ou non?

Les socket RAW, UDP, et TCP sont supportés et accessibles sur tous les vrais navigateurs via les websocket et socket.io.

Je lis :
http://en.wikipedia.org/wiki/Socket.IO
"It has two parts: a client-side library that runs in the browser, and a server-side library for node.js."

server side??? La demande est un client, pas un serveur!
Quand j'ai besoin de faire un appel de mon mobile vers un serveur IMAP, où est cette partie serveur? FFOS le contient-il? comment je fais un "npm install socket.io" (c'est sur le "how to" de Socket.IO) sur le mobile? Ca se fait tout seul par magie avec le "manifest"? Bref, comment on implémente un client IMAP qui ne communique avec personne d'autre que le serveur IMAP et qu'en IMAP (pas de chose à installer sur le serveur IMAP) avec FFOS?

J'avoue être perdu dans ce qui est possible de faire quand on me balance des noms comme ça et que je regarde ensuite ces noms mais que je vois une partie serveur alors qu'on parle de client…

Android SDK n'est pas un standard.

De fait
Oui, Windows n'est pas un standard non plus… Ou si.

Une application android ne tourne que sur android

Je pense que rien n’empêche de créer un autre OS implémentant l'API Android (on a bien des essais pour l'API Windows)
Tu es libre de proposer une implémentation d'API existante plutôt que de créer un n-ième spec.

Apache Cordova ou une application web sont des standards

Bonne blague… Ca utilise des standards (non de fait), mais à part ça…

L'api Firefox OS a vocation a devenir un standard.

Ah? Qui d'autre à part Mozilla a dit qu'il allait implémenter cette API?
En attendant, ça fait xkcd à fond : encore une nouvelle API à implémenter pour les développeurs… Et ne pas compter sur la mort des autres API, aucune autre entreprise concurrente n'ayant annoncé son intention d'implémenter cette nouvelle spec (tu parles d'un standard!)

Rien ne m’oblige à utiliser windows.

J'ai pris un nom "générique", remplace "portable" par l'équivalent technologique de ton OS ou tout autre technologie permettant d'installer facilement n'importe quelle version de Firefox (j'ose imaginer que ton OS de développement est assez moderne)

J’ai du mal à comprendre pourquoi certain développe en Qt4 alors que Qt5 est disponible ?

Ici, la question est : Pourquoi Mozilla devrait passer du temps à faire pour une version si vieille pour une nouvelle technologie et pour si peu d'utilisateurs non capables d'installer plus jeune? Combien de gens dans ce cas? Firefox ESR est à destination des entreprises sclérosées qui ne peuvent coder du HTML propre pour leurs app internes, généralement un codeur orienté web a 36 navigateurs pour les tests, alors un Firefox jeune devrait déjà être la.
L'exemple de Qt4 est HS, vu que qt4 est déjà codé.

une question de philosophie quoi !

Tant que tu assumes le prix… Ce n'est pas dommage que d'autres ne souhaitent pas payer du dév pour cette philosophie qui n'a plus court à part exception.
Surtout que j'ai bien écrit "à côté", et donc n'enlève rien à ta philosophie pour tout le reste.

bon, passons… il y a aura un autre pour demander Firefox 2 de toutes façons.

Rien ne t’empêche d'installer Firefox portable.
J'ai du mal à voir l’intérêt de prendre un vieux navigateur pour développer sur du tout nouveau, ça me parait logique.

J'avais commencé à écrire la même chose, puis je me suis rétracté : l'auteur n'a pas dit "l'humaniste", mais "la plus", et du coup c'est vrai : Mozilla dit merde aux standards et aux gens qui ne lui plaisent pas, mais moins que les autres. Du coup "la plus humaniste" se tient, juste que les autres sont pires, c'est une sorte de "la moins pire des non-humanistes" ;-).

Tu plaisantes???
Standard != Standard par un organisme tout ça.
Il y a 3 standards de fait en 2013 (bon, OK, 2.5 seulement), une pléthore d'autres prétendants.

Firefox OS est d'ailleurs autant standard que les autres (pas pire, mais pas mieux en volonté de normaliser)