Je vois fleurir des scripts pour aller faire des choses sur une page web, utilisant des libs plus ou moins efficace, parce que n'utilisant pas des "vrais" navigateurs. Par exemple, la page récupérée par mechanize n'est pas "vivante": le javascript n'est pas exécuté, et quand on voit que de plus en plus d'application génère du HTML à la volée : on ne peut pas faire grand chose sur ladite page web si le JS n'est pas executé. D'où d'ailleurs l'utilisation de iMacro pour certaines choses ici, infaisable avec mechanize si j'ai bien compris.
Alors Messieurs Dames, sachez qu'il existe des navigateurs "scriptables", c'est à dire que ce sont des navigateurs pilotables par un script. Et par navigateur, j'entends des vrais navigateurs, avec un vrai moteur de rendu HTML, un vrai moteur JS pour exécuter le js de la page etc. Avec ce genre d'outils, le code de la page web va donc s’exécuter pour de vrai.
Ainsi donc, vous écrivez un script (en JS), qui va dire au navigateur, "ouvre cette page", "click ici", "donne moi le contenu là" etc.. Et le navigateur va faire ce qu'on vous demande. Comme Mechanize, mais en vrai.
Le plus connu : PhantomJS, repose sur Webkit, le moteur de Safari et anciennement Chrome
Le challenger : SlimerJS, repose sur Gecko, le moteur de Firefox.
Le petit dernier : TrifleJS, repose sur Trident, le moteur de IE (encore en plein developpement)
sachant qu'ils ont à peu près la même API…
Et avec le framework CasperJS, l'API est encore plus simple à utiliser. (et "accessoirement", il sert beaucoup à réaliser des tests fonctionnels, en remplacement de Selenium et autres).
PS: ce commentaire est une pub déguisée, écrit par l'auteur de l'un de ces navigateurs ;-)
PS2: désolé :-)
, qui lui, n'a pas besoin de plusieurs Go de RAM (là, il utilise 375Mo avec 5 onglets ouverts).
Ces chiffres ne veulent rien dire. La quantité de RAM occupé par un navigateur dépend des sites qui sont affichées. Une simple page html avec trois paragraphes va demander beaucoup moins de mémoire qu'une appli comme google mail ou twitter, qui chargent des tonnes de JS et génèrent des milliers d’éléments HTML.
Et quand vous avez un navigateur avec plusieurs onglets ouverts, qui ne fait rien, et qui semblent prendre de plus en plus de mémoire, interrogez-vous si ce n'est pas un des sites ouverts qui "travaillent". Ex google mail: des mails arrivent, donc forcément, la liste des mails affichées s'allongent. et donc prend de plus en plus de mémoire.
XULrunner, c'était une technologie d'avenir en 2005, non ?
Disons que cette technologie s'est transformée. Pour rappel, une appli lancée par XULRunner, c'est une appli avec des fichiers XUL (du HTML like +++++, sous stéroïde), CSS pour le design et javascript pour le code. Voir du C++ pour des composants bas niveau (XPCOM) permettant de fournir des API au niveau JS (pratique aussi pour intégrer des libs binaires externes).
Pour l'aspect "appli lancée depuis mon bureau", Mozilla s'est tourné vers les webapps : une appli web peut ainsi être lancé en dehors du navigateur (mais avec son moteur), grâce au "web runner" (cf webapprt-stub dans le dossier Firefox). Techniquement, webapprt n'a pas énormément de différence avec l’exécutable xulrunner ;-)
Pour le langage XUL: beaucoup de choses ont été porté/spécifié vers HTML5 et CSS (en particulier le modèle de boite CSS : flexbox model).
Pour le language XBL (qui permet de faire des composants d'interface réutilisables): après un échec de standardisation de XBL2 il y a quelques années (trop complexe pour les implementeurs), la spec XBL2 a été découpée en plusieurs specs. On obtient les web components (shadow dom + templates html + scope CSS + …). En cours d’implémentation & spécification, dans chrome et firefox.
Et les webapi, permettent de remplacer l'appel à certains composants XPCOM de la plate-forme.
Bref, ce que proposait XULRunner (et propose toujours), préfigurait les technos d'aujourd'hui et de demain au niveau web ;-)
Même si aujourd'hui, on fait encore des choses largement plus puissantes avec XulRunner qu'avec les seules technos du web (HTML5…). Un navigateur scriptable par exemple ;-)
et on n'avait pas envie de reprendre les briques libres, non on recommence tout à 0
Ah ? Firefox OS, c'est un noyau linux (brique pas libre ?), gecko (brique pas libre ?), un bureau en HTML5 (Gaia, libre) et des applis html5.
Tu noteras que la philosophie du projet, c'est d'avoir tout en HTML5. Donc déjà, les bloatwares Java d'android, ça va pas trop le faire (surtout quand on vise un marché emergeant avec des téléphones low cost). Et malheureusement, un bureau en HTML5 pour mobile, ça n'existait pas. Donc ils ont fait Gaia.
Donc voilà, ils ont repris tout ce qu'ils ont pu reprendre. Je ne vois pas ce que tu peux leur reprocher (ne me parle pas de Tizen, la philosophie n'est pas tout à fait la même, et leurs applis HTML5 reposent sur des APIs propriétaires pour communiquer avec le matos, non proposées au W3C…)
Pour les développeurs, tu as toutes les API qu'un développeur attend pour un mobile qui sont en statut "unstable"
Bienvenu dans le monde du web. Il se trouve que, oui, le développeur web lambda utilise tous les jours des implémentations dont les spécifications sont instables. Surtout ceux qui ont rien à carrer des standards du web, et qui utilisent à tout va des styles -webkit-* ou des fonction webkit*…
Donc c'est normal de cracher sur un OS vendu (au niveau marketing) comme prêt alors qu'il ne l'est pas.
Faut pas non plus exagérer. Ça fonctionne. Faut juste pas trop en demander. De toute façon, vu les machines sur lesquelles FxOS est vendu, faut pas trop en demander.. Le Geeksphone, ça fait pas super stable, c'est normal, c'est vendu comme un téléphone pour développeur.
Pour les autres, tu penses bien que les opérateurs n'ont pas vendu à leurs clients des trucs qui ne fonctionnent pas. Ils ont des procédures de certifications exigeantes (et chiantes) pour qu'un téléphone soit commercialisé. La version de FxOS vendu avec les geeksphone n'est pas tout à fait la même que celle des téléphones chez Telefonica par ex.
plutôt que de lire des forums obscures qui racontent que des conneries, sur des choses sorties de leur contexte, va te cultiver sur wikipedia, ça te sera plus bénéfique
La politique du "release often, tous les trois mois" m'a tout de suite parue moins géniale, ça fait depuis que j'ai mon Geekphone Peak en avril/mai que j'attends au choix une MAJ OTA
D'une part, je pense que chez geeksphone, c'est le bordel complet coté organisation, vu la manière dont ils gèrent leurs commandes…
D'autre part pour faire une release, coté Mozilla, il faut que le système passe toutes les certifications imposées par les opérateurs. C'est super lourd…
Je ne sais pas si tout Firefox OS repose sur le code de Firefox
bah, tu enlèves l'interface XUL de Firefox et quelques composants, tu obtiens gecko, qui est utilisé dans Firefox OS (avec des differences au niveau du build, mais c'est globalement le même moteur de rendu, le même moteur JS etc…). Par contre c'est un "vieux" Gecko (18 je crois pour 1.0.1)
mais si c'est le cas il y a de quoi s'en faire, car tout l'OS est dans UN SEUL et UNIQUE processus
Il me semble que ce que tu dis là est totalement faux. Gecko est tout à fait capable de faire du multi-processus (ouvrir une page dans un process séparé). C'est utilisé dans Firefox pour Android, et … dans Firefox OS. (mais pas activé dans Firefox Desktop pour un tas de raisons valables, dont l'une est le temps de migrer tout le code de l'interface et des extensions pour tenir compte du multi process)
Bref, si ça lag, ce n'est pas la faute à du mono processus… Je pense que c'est plus dû au matos qui n'est pas super performant (que ce soit au nivo processeur, qu'au niveau mémoire disponible -> ça doit swapper à mort sur une page linuxfr qui contient des centaines de commentaires)
Mais après, tu peux toujours de compiler un firefox os et remplacer la version du téléphone. Cependant attention à la garantie, et à bien paramétrer le build…
Firefox OS est utilisable, mais pour des personnes averties je pense ou peu utilisatrice, dans le sens où il y a des petits bugs par ci, par là. Mais bonne nouvelle, tout ça évolue assez vite :-)
toujours est-il que mon Geeksphone me sert de téléphone pro (mais je ne suis pas un gros fana des smartphones), et que les sms, les appels téléphoniques se passent bien, tout comme le reste globalement.
Mais ça reste un OS jeune, peut-être manquera-t-il des fonctions que tu utilisais dans tes autres téléphones…
Si tu veux tester un peu la bete sans acheter, installe l'extension firefox os simulator dans Firefox.
cote serveur tu peux te permettre d'etre un peu plus "grumpy cat" et juste repondre "no" avec un 400.
Non. surtout si tu fais une application qui se dégrade correctement quand le JS n'est pas présent (ou pas exécuté parce que y'a un p*t*n de script de pub qui plante, genre à cause de adblock/ghostery). Il faut donc que quand la validation se fait coté serveur, le formulaire puisse se ré-afficher avec les bons messages d'erreur, et pas un "no".
j'ai été contacté via linkedin par Google, pour un poste sur Londres, il y a 3 ans. Bon, je n'ai pas réussi à passer tout les tests (mon foutu anglais….), donc je suis encore en région parisienne…
Les eval, c'est le mal. d'une part parce que cela peut avoir un certain potentiel en terme de trou de sécurité :-p. Même la doc officielle le dit. Mais en plus, on ne profites pas du tout des optimisations faite par le moteur PHP : pas de cache d'opcode et j'en passe.
Pour moi, l'utilisation de eval() est signe de problème d'architecture du code.. et de trous de sécu.
Tout ce qui est traduction est assurée par des volontaires ! Donc font les trad et les corrections sur leur temps libre. Donc non, ça ne peut pas être corrigé dans la minute de la découverte du bug.
Actuellement, quand un militaire français meurt, on peut se dire qu'il était prévenu, et qu'il avait signé pour. Ça craint, mais c'est comme ça. Avec des appelés, c'est du gâchis, seulement du gâchis.
Euh… les appelés étaient très rarement au front, mais restaient à l'arrière bien au chaud hein. Sauf peut être dans les années 1920-1950 …
Ça fait au moins quelques dizaines d'années que les missions de guerre sont réservées aux soldats de métier. Le service militaire n'était là que pour faire le recensement des gens "aptes" et préparer les gens à intégrer l'armée si un jour ils étaient appelés sous les drapeaux pour défendre le pays. Bref, à savoir manipuler une arme et à comprendre le fonctionnement de l'armée, pour au cas où. maintenant il y avait peut-être des exceptions, mais c'était alors sur la base du volontariat.
l'école publique propose une mixité sociale moins importante que l'on avait avec le service militaire. Dans une école, on cotoit des gens proches localement, donc en général proches culturellement, voir même proche socialement. Dans une école d'une cité du 93, tu ne vas pas trouver beaucoup d'enfants de
riche hein…
Alors qu'avec le service, tu te retrouvais vraiment dans un groupe de gens venu de tout horizon, social et culturel.
Bah, Mozilla propose de nombreuses API bas niveau, accessible en fonction des privilèges donnés à l'application. Comment crois tu que Firefox OS fonctionne sinon ? :-) Dans Firefox, TOUTES les applis sont en HTML/JS : le bureau, l'appli pour téléphoner, pour gérer les SMS, pour prendre des photos, pour gérer les albums photo, pour la cartographie etc.
À mon avis, tu n'es pas très informé : http://www.mozilla.org/fr/firefox/partners/ . ZTE, Alcatel, LG, Qualcomm… Et parmi la liste, il y a plein de nom que je ne connais pas, il y a probablement d'autres fabricants. Tout le reste, ce sont des opérateurs de téléphonie. Sans parler de ceux qui ne sont pas officiellement partenaires, mais qui ont fait des annonces : Sonny, Foxconn etc..
Bref, ça commence à faire un peu de monde, tu ne trouves pas ? [troll]peut être même plus que pour la version mobile de Windows[/troll] :-)
three thousand bugs, of which four hundred came from authors with apache.org mail addresses.
Ce qui laisse penser que, puisque OpenOffice est pris en charge par la fondation apache, des développeurs d'OpenOffice contribuent aussi à LibreOffice. Sympa :)
Vu les perfs de merde, je me demande bien qui utilise Firefox sur Android.
Moi..
Mais je me demande bien ce que tu appelle des perfs de merde. Tu te réfères aux version de Firefox Mobile d'il y a 2-3 ans ?
Parce que là, sur mon galaxy s2, j'ai ouvert le navigateur par défaut d'android, et Firefox Mobile. Les deux avec google.fr affiché (parce que le nav par défaut ouvre google.fr…)
Résultat:
- nav par défaut: ram 19.88MB
- firefox mobile: ram 2.65MB
Et dans Firefox, j'ai eu la page de google qui s'est affiché beaucoup plus vite (l'autre cherche encore à charger le logo de google..)
Dans un monde ou tout le monde se tourne vers le mobile, Firefox et Mozilla deviennent de moins en moins pertinent.
Oui c'est vrai, Firefox pour Android n'existe pas. D'ailleurs ce n'est pas comme si ils avaient été parmi les premiers à faire un navigateur pour le mobile. Qui se souvient de Minimo ? ;-)
c'est que la technologie est quand meme loin d'etre competitive avec Android ou Qt.
Faudrait mettre en avant des points de comparaison pour comparer la competitivité. Au doigt mouillé, je dirais qu'en nombre de développeur, les développeurs web sont bien plus nombreux que pour android, (et QT, n'en parlons pas).
Ce n'est pas forcement un modele d'ouverture (J'aimerais bien connaitre le rapport entre contribution paye par Mozilla et contribution libre exterieur).
Certes, les employés contribuent plus en terme de ligne de code que les contributeurs externes, vu qu'ils font ça à temps plein. Et encore, faudrait avoir des statistiques précises. Parce qu'il y a quand mêmes des milliers de contributeurs bénévoles, vs quelques centaines d'employés. Enfin bon, en admettant que les employés Mozilla produisent plus que les contributeurs externes, je ne vois pas en quoi ça ferait de Firefox OS et cie des projets moins ouvert. Tout est sur http://hg.mozilla.org et github (et quand je dis tout, c'est vraiment tout: logiciels, sites web etc). Tout le monde peut contribuer. Hello bugzilla!
Il y a une augmentation de la complexite du systeme
C'est vrai que QT et Android, sont des plateformes super simples en interne, avec très peu de couches logiciels… :-/
Firefox OS, c'est un noyau linux et un Gecko. Et c'est tout. Toutes les applis, y compris le bureau sont en HTML.
des risques de securite non negligeable (Faire un navigateur web dans un navigateur web par exemple).
Bon déjà, il y a plein de nouvelles techniques pour la secu des applis (exemple: https://developer.mozilla.org/en-US/docs/HTTP/Access_control_CORS ). De plus, avec XUL, Mozilla a une énorme expérience sur la secu "inter-frame". Le <iframe mozbrowser> utilisé dans Firefox OS pour faire un navigateur, est en fait la même chose qu'un <browser> en XUL. Et ça fonctionne quand même plutôt bien niveau sécu depuis 15 ans :-p
De grosse difficulte de deboggage (j'inclus aussi traquer les problemes de consomation d'energie).
Il y a plein d'outils pour débogguer (et même faire des tests fonctionnels) sur Firefox OS. Faut bien que les développeurs de Firefox OS puissent debogguer et tester :-p
est-ce qu'il y a un marche pour un telephone moins bien que la concurrence
Vu les ruptures de stock chez geeksphone et autres, je dirais que oui. Tout le monde n'a pas besoin d'un smartphone à 500 balles.
Faut voir si les operateurs sont toujours aussi fort et capable de faire manger n'importe quoi a leur client…
ah ba c'est sûr, si tu comptes utiliser le DOM pour animer les sprites d'un jeu, c'est pas vraiment le bon choix. Pour afficher une interface utilisateur, les perfs de DOM sont tout à fait raisonnables
batailler contre css pour avoir deux divs cote a cote sans que ca pete des que t'eternues
Ça fait longtemps que tu n'as pas fait de CSS ? Parce que, surprise, il y a tout ce qu'il faut pour faire ça sans que ça pète. Ça s'appelle le modèle de boite flexible. Et ça tombe bien, c'est implémenté dans Gecko, Webkit… Et si ça ne te convient pas, tu peux toujours te rabattre sur le modèle de boite flexible de XUL, implémenté depuis des années et des années dans Firefox (et dispo dans Firefox OS à priori). Voir les propriétés -moz-box*.
La "plateforme web" a énormément évolué ces dernières années, on peut maintenant faire énormément de choses, de manière efficace et performante. Faut se "mettre à jour" et remettre en cause certains préjugés.
# Outils mieux adaptés ?
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal HowTo: suppression de compte FB. Évalué à 6.
Hello,
Je vois fleurir des scripts pour aller faire des choses sur une page web, utilisant des libs plus ou moins efficace, parce que n'utilisant pas des "vrais" navigateurs. Par exemple, la page récupérée par mechanize n'est pas "vivante": le javascript n'est pas exécuté, et quand on voit que de plus en plus d'application génère du HTML à la volée : on ne peut pas faire grand chose sur ladite page web si le JS n'est pas executé. D'où d'ailleurs l'utilisation de iMacro pour certaines choses ici, infaisable avec mechanize si j'ai bien compris.
Alors Messieurs Dames, sachez qu'il existe des navigateurs "scriptables", c'est à dire que ce sont des navigateurs pilotables par un script. Et par navigateur, j'entends des vrais navigateurs, avec un vrai moteur de rendu HTML, un vrai moteur JS pour exécuter le js de la page etc. Avec ce genre d'outils, le code de la page web va donc s’exécuter pour de vrai.
Ainsi donc, vous écrivez un script (en JS), qui va dire au navigateur, "ouvre cette page", "click ici", "donne moi le contenu là" etc.. Et le navigateur va faire ce qu'on vous demande. Comme Mechanize, mais en vrai.
sachant qu'ils ont à peu près la même API…
Et avec le framework CasperJS, l'API est encore plus simple à utiliser. (et "accessoirement", il sert beaucoup à réaliser des tests fonctionnels, en remplacement de Selenium et autres).
PS: ce commentaire est une pub déguisée, écrit par l'auteur de l'un de ces navigateurs ;-)
PS2: désolé :-)
[^] # Re: Intérêt
Posté par Laurent J (site web personnel, Mastodon) . En réponse à la dépêche Haiku est vivant. Évalué à 7.
Ces chiffres ne veulent rien dire. La quantité de RAM occupé par un navigateur dépend des sites qui sont affichées. Une simple page html avec trois paragraphes va demander beaucoup moins de mémoire qu'une appli comme google mail ou twitter, qui chargent des tonnes de JS et génèrent des milliers d’éléments HTML.
Et quand vous avez un navigateur avec plusieurs onglets ouverts, qui ne fait rien, et qui semblent prendre de plus en plus de mémoire, interrogez-vous si ce n'est pas un des sites ouverts qui "travaillent". Ex google mail: des mails arrivent, donc forcément, la liste des mails affichées s'allongent. et donc prend de plus en plus de mémoire.
[^] # Re: JavaScript sans HTML5...
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal [Trolldi] Le langage plus approprié pour écrire des applications graphiques multiplateformes. Évalué à 4.
Disons que cette technologie s'est transformée. Pour rappel, une appli lancée par XULRunner, c'est une appli avec des fichiers XUL (du HTML like +++++, sous stéroïde), CSS pour le design et javascript pour le code. Voir du C++ pour des composants bas niveau (XPCOM) permettant de fournir des API au niveau JS (pratique aussi pour intégrer des libs binaires externes).
Pour l'aspect "appli lancée depuis mon bureau", Mozilla s'est tourné vers les webapps : une appli web peut ainsi être lancé en dehors du navigateur (mais avec son moteur), grâce au "web runner" (cf webapprt-stub dans le dossier Firefox). Techniquement, webapprt n'a pas énormément de différence avec l’exécutable xulrunner ;-)
Pour le langage XUL: beaucoup de choses ont été porté/spécifié vers HTML5 et CSS (en particulier le modèle de boite CSS : flexbox model).
Pour le language XBL (qui permet de faire des composants d'interface réutilisables): après un échec de standardisation de XBL2 il y a quelques années (trop complexe pour les implementeurs), la spec XBL2 a été découpée en plusieurs specs. On obtient les web components (shadow dom + templates html + scope CSS + …). En cours d’implémentation & spécification, dans chrome et firefox.
Et les webapi, permettent de remplacer l'appel à certains composants XPCOM de la plate-forme.
Bref, ce que proposait XULRunner (et propose toujours), préfigurait les technos d'aujourd'hui et de demain au niveau web ;-)
Même si aujourd'hui, on fait encore des choses largement plus puissantes avec XulRunner qu'avec les seules technos du web (HTML5…). Un navigateur scriptable par exemple ;-)
[^] # Re: JavaScript sans HTML5...
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal [Trolldi] Le langage plus approprié pour écrire des applications graphiques multiplateformes. Évalué à 4.
Il y a encore pas mal d'appli.
https://developer.mozilla.org/en-US/docs/XULRunner_Hall_of_Fame
Bon ok, c'est peu comparé à du QT ou gtk…
[^] # Re: Ils doivent se bouger le popotin ! Firefox OS 1.2
Posté par Laurent J (site web personnel, Mastodon) . En réponse à la dépêche Firefox OS 1.1 et autres actualités. Évalué à 2.
Ah ? Firefox OS, c'est un noyau linux (brique pas libre ?), gecko (brique pas libre ?), un bureau en HTML5 (Gaia, libre) et des applis html5.
Tu noteras que la philosophie du projet, c'est d'avoir tout en HTML5. Donc déjà, les bloatwares Java d'android, ça va pas trop le faire (surtout quand on vise un marché emergeant avec des téléphones low cost). Et malheureusement, un bureau en HTML5 pour mobile, ça n'existait pas. Donc ils ont fait Gaia.
Donc voilà, ils ont repris tout ce qu'ils ont pu reprendre. Je ne vois pas ce que tu peux leur reprocher (ne me parle pas de Tizen, la philosophie n'est pas tout à fait la même, et leurs applis HTML5 reposent sur des APIs propriétaires pour communiquer avec le matos, non proposées au W3C…)
Bienvenu dans le monde du web. Il se trouve que, oui, le développeur web lambda utilise tous les jours des implémentations dont les spécifications sont instables. Surtout ceux qui ont rien à carrer des standards du web, et qui utilisent à tout va des styles -webkit-* ou des fonction webkit*…
Faut pas non plus exagérer. Ça fonctionne. Faut juste pas trop en demander. De toute façon, vu les machines sur lesquelles FxOS est vendu, faut pas trop en demander.. Le Geeksphone, ça fait pas super stable, c'est normal, c'est vendu comme un téléphone pour développeur.
Pour les autres, tu penses bien que les opérateurs n'ont pas vendu à leurs clients des trucs qui ne fonctionnent pas. Ils ont des procédures de certifications exigeantes (et chiantes) pour qu'un téléphone soit commercialisé. La version de FxOS vendu avec les geeksphone n'est pas tout à fait la même que celle des téléphones chez Telefonica par ex.
[^] # Re: Mozilla et la confiance dans la bête
Posté par Laurent J (site web personnel, Mastodon) . En réponse à la dépêche Firefox OS 1.1 et autres actualités. Évalué à 1.
plutôt que de lire des forums obscures qui racontent que des conneries, sur des choses sorties de leur contexte, va te cultiver sur wikipedia, ça te sera plus bénéfique
http://en.wikipedia.org/wiki/The_Book_of_Mozilla
[^] # Re: Ils doivent se bouger le popotin ! Firefox OS 1.2
Posté par Laurent J (site web personnel, Mastodon) . En réponse à la dépêche Firefox OS 1.1 et autres actualités. Évalué à 2.
D'une part, je pense que chez geeksphone, c'est le bordel complet coté organisation, vu la manière dont ils gèrent leurs commandes…
D'autre part pour faire une release, coté Mozilla, il faut que le système passe toutes les certifications imposées par les opérateurs. C'est super lourd…
bah, tu enlèves l'interface XUL de Firefox et quelques composants, tu obtiens gecko, qui est utilisé dans Firefox OS (avec des differences au niveau du build, mais c'est globalement le même moteur de rendu, le même moteur JS etc…). Par contre c'est un "vieux" Gecko (18 je crois pour 1.0.1)
Il me semble que ce que tu dis là est totalement faux. Gecko est tout à fait capable de faire du multi-processus (ouvrir une page dans un process séparé). C'est utilisé dans Firefox pour Android, et … dans Firefox OS. (mais pas activé dans Firefox Desktop pour un tas de raisons valables, dont l'une est le temps de migrer tout le code de l'interface et des extensions pour tenir compte du multi process)
Bref, si ça lag, ce n'est pas la faute à du mono processus… Je pense que c'est plus dû au matos qui n'est pas super performant (que ce soit au nivo processeur, qu'au niveau mémoire disponible -> ça doit swapper à mort sur une page linuxfr qui contient des centaines de commentaires)
[^] # Re: Ils doivent se bouger le popotin ! Firefox OS 1.2
Posté par Laurent J (site web personnel, Mastodon) . En réponse à la dépêche Firefox OS 1.1 et autres actualités. Évalué à 0.
Le monde ne s'est pas fait en un jour. Pareil pour Firefox OS ;-)
[^] # Re: Mise à jour
Posté par Laurent J (site web personnel, Mastodon) . En réponse à la dépêche Firefox OS 1.1 et autres actualités. Évalué à 3.
Par les opérateurs je crois.
Mais après, tu peux toujours de compiler un firefox os et remplacer la version du téléphone. Cependant attention à la garantie, et à bien paramétrer le build…
[^] # Re: Téléphone principal
Posté par Laurent J (site web personnel, Mastodon) . En réponse à la dépêche Firefox OS 1.1 et autres actualités. Évalué à 3.
Firefox OS est utilisable, mais pour des personnes averties je pense ou peu utilisatrice, dans le sens où il y a des petits bugs par ci, par là. Mais bonne nouvelle, tout ça évolue assez vite :-)
toujours est-il que mon Geeksphone me sert de téléphone pro (mais je ne suis pas un gros fana des smartphones), et que les sms, les appels téléphoniques se passent bien, tout comme le reste globalement.
Mais ça reste un OS jeune, peut-être manquera-t-il des fonctions que tu utilisais dans tes autres téléphones…
Si tu veux tester un peu la bete sans acheter, installe l'extension firefox os simulator dans Firefox.
[^] # Re: Mozilla et la confiance dans la bête
Posté par Laurent J (site web personnel, Mastodon) . En réponse à la dépêche Firefox OS 1.1 et autres actualités. Évalué à 2.
t'es vraiment un grand malade…
[^] # Re: Angular JS vs Server Side framework
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Symfony, AngularJS, ..... Évalué à 3.
Non. surtout si tu fais une application qui se dégrade correctement quand le JS n'est pas présent (ou pas exécuté parce que y'a un p*t*n de script de pub qui plante, genre à cause de adblock/ghostery). Il faut donc que quand la validation se fait coté serveur, le formulaire puisse se ré-afficher avec les bons messages d'erreur, et pas un "no".
[^] # Re: etre ou ne pas etre
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Ras le bol des plateformes d'e-recrutement. Évalué à 3.
j'ai été contacté via linkedin par Google, pour un poste sur Londres, il y a 3 ans. Bon, je n'ai pas réussi à passer tout les tests (mon foutu anglais….), donc je suis encore en région parisienne…
[^] # Re: Un très rapide petit tour dans les sources
Posté par Laurent J (site web personnel, Mastodon) . En réponse à la dépêche PluXml 5.2 le CMS propulsé à l'XML est de sortie. Évalué à 2.
Les eval, c'est le mal. d'une part parce que cela peut avoir un certain potentiel en terme de trou de sécurité :-p. Même la doc officielle le dit. Mais en plus, on ne profites pas du tout des optimisations faite par le moteur PHP : pas de cache d'opcode et j'en passe.
Pour moi, l'utilisation de eval() est signe de problème d'architecture du code.. et de trous de sécu.
[^] # Re: Le menu outils est devenu "Outils de développement"
Posté par Laurent J (site web personnel, Mastodon) . En réponse à la dépêche 23 de Firefox. Évalué à 1.
Justement, les traductions sont réalisées par des contributeurs, pas par Moz Corp.
Merci d'avoir un peu d'indulgence.
Et tu peux les aider pour baisser ce niveau "d'amateurisme", puisque cela semble si facile pour toi de traduire un logiciel.
[^] # Re: Le menu outils est devenu "Outils de développement"
Posté par Laurent J (site web personnel, Mastodon) . En réponse à la dépêche 23 de Firefox. Évalué à 3.
Tout ce qui est traduction est assurée par des volontaires ! Donc font les trad et les corrections sur leur temps libre. Donc non, ça ne peut pas être corrigé dans la minute de la découverte du bug.
Merci de votre compréhension.
[^] # Re: en France, c'etait mieux avant...
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Armée Suisse, modèle ou pas ?. Évalué à 1.
Euh… les appelés étaient très rarement au front, mais restaient à l'arrière bien au chaud hein. Sauf peut être dans les années 1920-1950 …
Ça fait au moins quelques dizaines d'années que les missions de guerre sont réservées aux soldats de métier. Le service militaire n'était là que pour faire le recensement des gens "aptes" et préparer les gens à intégrer l'armée si un jour ils étaient appelés sous les drapeaux pour défendre le pays. Bref, à savoir manipuler une arme et à comprendre le fonctionnement de l'armée, pour au cas où. maintenant il y avait peut-être des exceptions, mais c'était alors sur la base du volontariat.
[^] # Re: en France, c'etait mieux avant...
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Armée Suisse, modèle ou pas ?. Évalué à 7.
l'école publique propose une mixité sociale moins importante que l'on avait avec le service militaire. Dans une école, on cotoit des gens proches localement, donc en général proches culturellement, voir même proche socialement. Dans une école d'une cité du 93, tu ne vas pas trouver beaucoup d'enfants de
riche hein…
Alors qu'avec le service, tu te retrouvais vraiment dans un groupe de gens venu de tout horizon, social et culturel.
[^] # Re: Même analyse que l'auteur de l'article
Posté par Laurent J (site web personnel, Mastodon) . En réponse à la dépêche Ubuntu Edge, premier smartphone Canonical : convergent, haut de gamme, financement participatif. Évalué à 7.
Bah, Mozilla propose de nombreuses API bas niveau, accessible en fonction des privilèges donnés à l'application. Comment crois tu que Firefox OS fonctionne sinon ? :-) Dans Firefox, TOUTES les applis sont en HTML/JS : le bureau, l'appli pour téléphoner, pour gérer les SMS, pour prendre des photos, pour gérer les albums photo, pour la cartographie etc.
[^] # Re: Même analyse que l'auteur de l'article
Posté par Laurent J (site web personnel, Mastodon) . En réponse à la dépêche Ubuntu Edge, premier smartphone Canonical : convergent, haut de gamme, financement participatif. Évalué à 5.
Nulle part ?? un constructeur ??
À mon avis, tu n'es pas très informé : http://www.mozilla.org/fr/firefox/partners/ . ZTE, Alcatel, LG, Qualcomm… Et parmi la liste, il y a plein de nom que je ne connais pas, il y a probablement d'autres fabricants. Tout le reste, ce sont des opérateurs de téléphonie. Sans parler de ceux qui ne sont pas officiellement partenaires, mais qui ont fait des annonces : Sonny, Foxconn etc..
Bref, ça commence à faire un peu de monde, tu ne trouves pas ? [troll]peut être même plus que pour la version mobile de Windows[/troll] :-)
# Contributeurs OpenOffice
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal LibreOffice 4.1 est là !. Évalué à 2.
Dans les releases notes, il est dit:
Ce qui laisse penser que, puisque OpenOffice est pris en charge par la fondation apache, des développeurs d'OpenOffice contribuent aussi à LibreOffice. Sympa :)
[^] # Re: ça marchera jamais?
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Ubuntu Edge : Révolution ou bide annoncé ?. Évalué à 5.
Moi..
Mais je me demande bien ce que tu appelle des perfs de merde. Tu te réfères aux version de Firefox Mobile d'il y a 2-3 ans ?
Parce que là, sur mon galaxy s2, j'ai ouvert le navigateur par défaut d'android, et Firefox Mobile. Les deux avec google.fr affiché (parce que le nav par défaut ouvre google.fr…)
Résultat:
- nav par défaut: ram 19.88MB
- firefox mobile: ram 2.65MB
Et dans Firefox, j'ai eu la page de google qui s'est affiché beaucoup plus vite (l'autre cherche encore à charger le logo de google..)
[^] # Re: ça marchera jamais?
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Ubuntu Edge : Révolution ou bide annoncé ?. Évalué à 5. Dernière modification le 24 juillet 2013 à 10:37.
mais bien sûr :-)
Oui c'est vrai, Firefox pour Android n'existe pas. D'ailleurs ce n'est pas comme si ils avaient été parmi les premiers à faire un navigateur pour le mobile. Qui se souvient de Minimo ? ;-)
Faudrait mettre en avant des points de comparaison pour comparer la competitivité. Au doigt mouillé, je dirais qu'en nombre de développeur, les développeurs web sont bien plus nombreux que pour android, (et QT, n'en parlons pas).
Certes, les employés contribuent plus en terme de ligne de code que les contributeurs externes, vu qu'ils font ça à temps plein. Et encore, faudrait avoir des statistiques précises. Parce qu'il y a quand mêmes des milliers de contributeurs bénévoles, vs quelques centaines d'employés. Enfin bon, en admettant que les employés Mozilla produisent plus que les contributeurs externes, je ne vois pas en quoi ça ferait de Firefox OS et cie des projets moins ouvert. Tout est sur http://hg.mozilla.org et github (et quand je dis tout, c'est vraiment tout: logiciels, sites web etc). Tout le monde peut contribuer. Hello bugzilla!
C'est vrai que QT et Android, sont des plateformes super simples en interne, avec très peu de couches logiciels… :-/
Firefox OS, c'est un noyau linux et un Gecko. Et c'est tout. Toutes les applis, y compris le bureau sont en HTML.
Bon déjà, il y a plein de nouvelles techniques pour la secu des applis (exemple: https://developer.mozilla.org/en-US/docs/HTTP/Access_control_CORS ). De plus, avec XUL, Mozilla a une énorme expérience sur la secu "inter-frame". Le
<iframe mozbrowser>utilisé dans Firefox OS pour faire un navigateur, est en fait la même chose qu'un<browser>en XUL. Et ça fonctionne quand même plutôt bien niveau sécu depuis 15 ans :-pIl y a plein d'outils pour débogguer (et même faire des tests fonctionnels) sur Firefox OS. Faut bien que les développeurs de Firefox OS puissent debogguer et tester :-p
Vu les ruptures de stock chez geeksphone et autres, je dirais que oui. Tout le monde n'a pas besoin d'un smartphone à 500 balles.
Firefox OS n'est pas n'importe quoi.
[^] # Re: ça marchera jamais?
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Ubuntu Edge : Révolution ou bide annoncé ?. Évalué à 4.
ah ba c'est sûr, si tu comptes utiliser le DOM pour animer les sprites d'un jeu, c'est pas vraiment le bon choix. Pour afficher une interface utilisateur, les perfs de DOM sont tout à fait raisonnables
Ça fait longtemps que tu n'as pas fait de CSS ? Parce que, surprise, il y a tout ce qu'il faut pour faire ça sans que ça pète. Ça s'appelle le modèle de boite flexible. Et ça tombe bien, c'est implémenté dans Gecko, Webkit… Et si ça ne te convient pas, tu peux toujours te rabattre sur le modèle de boite flexible de XUL, implémenté depuis des années et des années dans Firefox (et dispo dans Firefox OS à priori). Voir les propriétés -moz-box*.
La "plateforme web" a énormément évolué ces dernières années, on peut maintenant faire énormément de choses, de manière efficace et performante. Faut se "mettre à jour" et remettre en cause certains préjugés.
[^] # Re: ça marchera jamais?
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Ubuntu Edge : Révolution ou bide annoncé ?. Évalué à 6.
Et? Gecko (son moteur de rendu et son compilateur JS) est optimisé pour ce qu'il doit faire. C'est quoi la différence ?
Il y a tout ce qu'il faut pour développer une app en html/js, et pour Firefox OS qui plus est.