Ubuntu vient de réveler ce qui se cachait derrière les teasers publiés depuis des semaines sur le site.
En résumé il s'agit d'un smartphone très haut de gamme, le "Ubuntu Edge", qui fait l'objet d'une campagne de financement participatif (crowdsourcing) sur la plate-forme Indiegogo.
Les caractéristiques techniques sont alléchantes puisqu'on relève, sur le blog de Jono Bacon, les détails suivants :
- Ecran 4,5 pouces avec glace en saphir
- Résolution de 1280 x 720
- 4 Go de RAM
- 128 GO de stockage
- Appareil photo 8MP à l'arrière et 2MP à l'avant.
- 4G-LTE
- Batterie silicon anode (je ne sais pas ce que c'est que ce truc)
Ce qui est encore plus intéressant c'est que ce smartphone est qualifié de "fully converged Ubuntu device". Cela signifie que vous pouvez le brancher sur un moniteur et il vous offrira une interface Ubuntu classique comme si c'était un desktop traditionnel. Plus besoin d'unité centrale fixe, tout est sous la main et on le branche ou on veut.
Maintenant, après le marketing, les questions qui fâchent.
Il est évident que les processeurs ARM d'un smartphone ne sont pas au niveau de ce qu'offre un desktop Intel ou AMD. L'annonce de l'Ubuntu Edge indique seulement qu'il contiendra "the fastest multi-core CPU" ce qui n'est pas d'une précision renversante. Quel sera le gap par rapport à un ordinateur classique ? Est-ce que les performances seront "suffisantes" ?
Une autre inconnue est la pile logicielle Ubuntu du Edge. Il est annoncé que l'appareil sera pleinement compatible Android afin de profiter de la gigantesque logithèque déjà existante. En gros cela revient à faire tourner un Android et à lancer l'interface Ubuntu comme si c'était une application root par dessus.
Par la suite (mais pas au lancement apparemment) on pourra ne lancer que la pile logicielle Ubuntu sans faire appel à Android. Les mises à jour sont garanties sur au moins trois ans.
Une autre question concerne la campagne Indiegogo. Pourquoi lancer une telle campagne, surtout avec un objectif à atteindre aussi énorme (32 millions de dollars !). Est-ce que Canonical n'a pas assez d'argent pour produire seule le Edge ? Est-ce pour rassembler et fidéliser les aficionados ?
On peut noter que les premiers souscripteurs (ceux qui feront leur promesse de don le 23 juillet) auront un Edge à 600 dollars alors que les donateurs plus tardifs devront payer 810 dollars.
Avis perso : ça marchera jamais.
Avec la concurrence démente entre iOS et Android il n'y a que très peu de place sur le marché des smartphones. Il me semble que Mozilla à bien joué en coup en visant un segment de marché plus bas et en optant pour des applis full HTML5. Ce sont des facteurs qui peuvent jouer pour parvenir à se construite une niche écologique.
En revanche le Ubuntu Edge ne me semble pas apporter quoi que ce soit lui permettant de se différencier vraiment. Jouer la haute technologie c'est déjà la stratégie d'Apple ou de Samsung.
Je ne sais pas quel va être le résultat de la campagne Indiegogo (565 153 $ au moment ou j'écris) mais la cible paraît difficile à atteindre. D'ailleurs la FAQ évoque ce point et annonce que si les 32 millions ne sont pas atteints il n'y aura pas de Edge et Canonical se contentera de passer des accords avec des fabricants pour déployer Ubuntu sur des smartphones déjà disponibles.
# Ubuntu for Android
Posté par Benjamin Verhaeghe (site web personnel) . Évalué à 4.
Il s'agit d'un téléphone pensé pour réaliser le UBUNTU FOR ANDROID, et cela permet de répondre à plusieurs de tes questions:
Le téléphone est pensé pour cela, et c'est pourquoi les spécifications de ce téléphone sont loin des spécifications d'entrée de gamme.
Il s'agit de préparer la production en série de ces téléphones portable pour diminuer les coûts. cela permet de s'assurer un nombre de ventes conséquent et donc un retour sur investissement (ou du moins des pertes mois importantes que se lancer avec seulement des études de marché)
Android vise prioritairement l'entrée de gamme. Backberry et IOS le haut de gamme. Ici Ubuntu apporte une nouvelle fonctionnalité (Ubuntu for Android), qui transforme le téléphone en mini ordinateur…
[^] # Re: Ubuntu for Android
Posté par lenod . Évalué à 8.
J'ajouterais, en réaction à :
et
Créer une telle campagne sert justement à ne pas prendre de risque et être sûr qu'il y a un marché.
Si tu as raison et qu'il n'y en a pas, tant pis, mais ça vallait le coup d'essayer.
Concernant la somme (32 millions), ce n'est pas ça qui compte, c'est le nombre : 50 000, ce qui est tout à fait raisonnable, ils sont d'ailleurs à 2% en seulement quelques heures.
Ce n'est pas le genre de téléphone que j'achèterais (quoique, s'il est valable en tant que pc …), mais j'y crois.
[^] # Re: Ubuntu for Android
Posté par case42 (site web personnel) . Évalué à 5.
Et a l'heure ou j’écris, ils sont a $3.2M , soit 10% … Encourageant…
[^] # Re: Ubuntu for Android
Posté par NilugeKiWi . Évalué à 4.
Ils ont surtout vendu la totalité des 5000 téléphones à pas cher ($600 au lieu de $830). Les plus cher auront peut-être plus de mal à décoller.
[^] # Re: Ubuntu for Android
Posté par Fabimaru (site web personnel) . Évalué à 6.
Je pense que pour 90% de mon utilisation (pour la retouche photo ça doit être un peu poussif) c'est ce qu'il me faut.
Je vois bien comme avenir de l'ordi des petits boitiers avec ARM et surtout pas de ventilo. Et des drivers graphiques libres (ce qu'il manque à mon Odroid).
[^] # Re: Ubuntu for Android
Posté par claudex . Évalué à 10.
On ne doit pas avoir la même définition d'entrée de gamme.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Ubuntu for Android
Posté par dinomasque . Évalué à 10.
Ni la même notion de priorité ;)
Android est le seul système pour smartphones à adresser quasiment tout le spectre de gamme, du smartphone basique à moins de 100€ jusqu'au haut de gamme.
BeOS le faisait il y a 20 ans !
# ça marchera jamais?
Posté par devnewton 🍺 (site web personnel) . Évalué à 1.
Je trouve cette annonce intéressante, car si mon vieux no friture phone devait mourir, je ne saurais par quoi le remplacer:
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: ça marchera jamais?
Posté par damien . Évalué à 2.
A mon avis, il ne faut plus voir le téléphone comme un téléphone. Mais a mon avis, comme l'ordinateur de demain que tu trimballes dans ta poche. Un truc qui serait cool, c'est de projeter l'écran du smartphone sur la table. Et que le smartphone il tienne debout.
[^] # Re: ça marchera jamais?
Posté par Zylabon . Évalué à 5.
T'as raison les écrans LCD ça marche trop bien en plein soleil, ça peut pas durer.
Please do not feed the trolls
[^] # Re: ça marchera jamais?
Posté par deasy . Évalué à 1.
Attendons les verres traités qui diminuent leur réflexion :)
[^] # Re: ça marchera jamais?
Posté par damien . Évalué à -4.
Ok. Et si je dis qu'il va falloir aller dans le train et prendre tout le temps ça pochette de cassette avec soi ?? Je sais plus comment ça s'appelle. Ca serait cool d'avoir un clavier laser !! :-)
https://www.youtube.com/watch?v=ONCLyqNEJY0&feature=player_embedded
[^] # Re: ça marchera jamais?
Posté par Astaoth . Évalué à 5.
Et un petit Jolla Phone sous un Linux (le descendant le Meego) avec matériel évolutif ? En prime il ne coutera pas un bras avec une dalle en saphir.
Emacs le fait depuis 30 ans.
[^] # Re: ça marchera jamais?
Posté par fredix . Évalué à 1.
Perso j'hésiterai. Mais le gros avantage d'ubuntu est qu'il y a tout l'écosystème derrière ; l'OS, le store, des communautés de users et de dev … Shuttlework aurait du racheter l'équipe de jolla, parce que s'il met du python dans son smartphone c'est pas la peine :)
[^] # Re: ça marchera jamais?
Posté par Astaoth . Évalué à 2.
L'avantage de Jolla c'est que tu as derrière toute la communauté Maemo/Meego/Mer, l'éco-système Qt, et les appli Androïd officiellement suopportées. J'ai l'impression que Ubuntu a surtout un éco-système desktop pour le moment.
Vu le taux d'activité de la communauté Maemo/Meego/Mer (à titre indicatif : le Nokia N900 a toujours des mises à jours de l'OS alors que son support officiel est abandonné depuis plus de 2 ans), je pense qu'il y aura rapidement des évolutions matériels intéressantes, via le système de Other Half du téléphone.
Emacs le fait depuis 30 ans.
[^] # Re: ça marchera jamais?
Posté par fredix . Évalué à 4.
Oui je dis pas le contraire. Je dis juste que si jolla avait rejoint Canonical, ca aurait pu faire un truc énorme. Là les 2 projets séparés qui vont taper + ou - le même profil de client ca va être tendu pour les 2.
[^] # Re: ça marchera jamais?
Posté par gouttegd (site web personnel) . Évalué à 5.
Tu le sais sans doute déjà (vu le « souvent »), mais Android est tout-à-fait utilisable sans compte Google (même si tout est fait pour t’inciter à en avoir un).
Le plus pénible sans compte Google, ce sont tous ces développeurs qui semblent complètement ignorer qu’il existe d’autres marchés que le PlayStore, et qui ne proposent leurs applications que sur ce dernier… Mais bon la plupart du temps, les applications en questions sont privatrices/propriétaires/non-libres, donc ce n’est pas une grande perte.
[^] # Re: ça marchera jamais?
Posté par Parleur . Évalué à -10.
[^] # Re: ça marchera jamais?
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 9.
C'est marrant, pour les deux autres types de téléphone, tu donnes des arguments concrets pour lesquels tu ne les veut pas. Mais pour Firefox OS, non, ça a juste "l'air un peu pourri".
Donc,
Dans tous les cas, je te conseille d'en tester un quelques jours avant d'avoir un avis aussi flou ;-)
[^] # Re: ça marchera jamais?
Posté par fredix . Évalué à -9.
c'est pourri. moi je veux pas de saloperie de pseudo "app" en html/js sur mon smartphone.
[^] # Re: ça marchera jamais?
Posté par claudex . Évalué à 8.
C'est quoi la différence avec une vrai "app" en xml/java ?
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: ça marchera jamais?
Posté par fredix . Évalué à -9.
une VM extrêmement optimisé, un SDK concu pour ? mais la référence c'est iOS et son env de dev.
[^] # Re: ça marchera jamais?
Posté par Laurent J (site web personnel, Mastodon) . É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.
[^] # Re: ça marchera jamais?
Posté par devnewton 🍺 (site web personnel) . Évalué à 3.
Mais ça ne donne pas envie!
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: ça marchera jamais?
Posté par kursus_hc . Évalué à 4.
Ça ne TE donne pas envie. Tu n'as peut-être pas remarqué mais html/css/js a quelque peu la cote en ce moment.
[^] # Re: ça marchera jamais?
Posté par fredix . Évalué à 2.
Qui prétend parler au nom de la terre entière ? …. Macdo/Windows ont aussi la cote hein.
[^] # Re: ça marchera jamais?
Posté par barmic . Évalué à 3.
Ça montre juste que l'argument "Firefox OS c'est nul, moi je veux des vraies application" est purement subjectif. Bref c'est du « moi j'aime pas ».
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: ça marchera jamais?
Posté par claudex . Évalué à 3.
Il n'a pas dit le contraire il me semble.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: ça marchera jamais?
Posté par barmic . Évalué à 3.
Disons que quand on voit des phrases aussi tranchées que « ça c'est des vrais app », on a du mal à y voir autre chose qu'un présent de vérité général et pas un avis. Donc soit on saute dans le troll
soit on laisse les gens cracher sur ce qui ne leur plaît pas sans le moindre argumentIci, on est sur linuxfr…Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: ça marchera jamais?
Posté par claudex . Évalué à 3.
Il y a plusieurs personnes impliqués et une seule l'a dit dans ce thread. Comme tu ne lui répondais pas directement, on peut imaginé que tu parlais du contexte général du thread.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: ça marchera jamais?
Posté par devnewton 🍺 (site web personnel) . Évalué à -7.
Ce n'est pas subjectif si tu es développeur.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: ça marchera jamais?
Posté par claudex . Évalué à 4.
Si. Je préfère faire une interface web que les trucs auxquels j'ai touché pour faire du natif.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: ça marchera jamais?
Posté par devnewton 🍺 (site web personnel) . Évalué à 0.
Le choix d'une plateforme de développement se fait surtout sur des critères objectifs. Pour mon domaine (dev de jeux sur temps libre), Javascript n'est pas un bon choix: trop lent et trop difficile à maintenir.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: ça marchera jamais?
Posté par G.bleu (site web personnel) . Évalué à 2.
Au vu de asm.js, j'ai un peu de mal avec l'argument "trop lent". En fait ça me fait penser aux mecs qui disent que Java est "trop lent"…
D'ailleurs, vu que ce dernier est la solution que tu as choisis pour Newton Adventure, j'aimerais bien que tu développe ton avis sur Javascript.
Personnellement de ce que j'ai fait de dev avec Javascript et j'aurai plutôt tendance à dire que c'est un langage trop permissif ce qui rend le code rapidement très sale si on n'y fait pas attention. Par contre la rapidité de développement et de déploiement est vraiment flagrante comparé à du C++
[^] # Re: ça marchera jamais?
Posté par devnewton 🍺 (site web personnel) . Évalué à 2.
Pour Newton Adventure, je n'ai pas choisi Java, ça a démarré comme un exercice après une formation.
Ce n'est pas vraiment adapté pour les jeux, mais la JVM mets une grosse fessée cul nul aux meilleurs interpréteurs Javascript.
Pour la combo html5/webgl/asm.js, j'attends de voir, toutes les démos que j'ai lancé rament ou plantent…
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: ça marchera jamais?
Posté par CrEv (site web personnel) . Évalué à 5.
Oué enfin tu aurais très bien pu garder l'idée et le faire avec autre chose ensuite, non ?
Ha oui, tu veux dire qu'une bête application sur JVM consomme au moins autant de RAM qu'un navigateur qui exécute du Javascript. C'est bien ça ? ;-)
[^] # Re: ça marchera jamais?
Posté par devnewton 🍺 (site web personnel) . Évalué à 3.
Une fois que tu as un projet qui tourne sans défaut majeur, ce n'est pas très motivant de tout recommencer…
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: ça marchera jamais?
Posté par saltimbanque (site web personnel) . Évalué à 2.
pourtant, une infinité d'exemples!
[^] # Re: ça marchera jamais?
Posté par cedric . Évalué à 8.
C'est marrant, mais mon experience avec Java n'a jamais ete vraiment de le prendre pour un foudre de guerre. Ca fait dix ans qu'on me dit que c'est aussi rapide que le natif, ca fait dix ans que ce n'est pas mon experience.
Sinon petite lecture sur le JS etant trop lent : http://sealedabstract.com/rants/why-mobile-web-apps-are-slow/ . Il y a juste un point qui manque dans cette article, c'est le rapport avec la consommation de batterie. Pour faire simple, si tu es deux fois plus lent, tu as deux fois moins de batterie. C'est pas beaucoup plus complique que ca.
Pour rentrer dans le detail, plus tu utilises de memoire, plus tu consommes de batterie (l'acces a chaque niveau de memoire est plus couteux que le niveau precedent). Plus tu te reposes sur OpenGL pour faire de la magie, plus ton GPU va consommer. Plus tu fais de traitement inutile cote CPU, plus ceci vont te couter.
La majorite des developpeurs sur plateforme mobile n'a strictement aucune competence pour optimiser la consomation de batterie. En plus les environnements de developpement ne mette pas cela en avant. Resultat, ca rajoute une grosse couche de ralentissement et de consommation inutile en plus de ce que ta techno dans le meilleur des cas peut faire. Comme tout cela se demultiplie, partir sur du HTML/JS pour faire du mobile va necessiter d'accepter d'avoir moins d'autonomie… Mais bon de nos jours ne pas avoir une journee d'autonomie, c'est normal, alors ca devrait passer.
[^] # Re: ça marchera jamais?
Posté par devnewton 🍺 (site web personnel) . Évalué à 1.
Niveau perf on a C++ > Java >> Javascript. Il n'y a malheureusement pas grand chose d'utilisable entre C++ et Java….
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: ça marchera jamais?
Posté par groumly . Évalué à -2.
Ca depend de quoi tu parles.
Une fois la vm chargee et chauffee, oui, ca va vite.
Mais le temps de chargement + chauffe avoisine la session moyenne d'une appli mobile, et l'overhead memoire de java et de la jvm, gc et tout le tsintsin, c'est pas negligeable.
Rajoute les probleme de gc non deterministe, et quand t'es contraint en memoire, sans swap, c'est loin d'etre un bon choix (et ce malgre tous les efforts que google a pu mettre dna s dalvik).
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: ça marchera jamais?
Posté par Dr BG (site web personnel) . Évalué à 2.
Il n'y a pas de problème de GC (et plus généralement de mémoire) avec JavaScript ?
[^] # Re: ça marchera jamais?
Posté par ckyl . Évalué à 9.
Si. Javascript et Java utilisent exactement la même approche sur ce point. Sauf que les GC de Javascript ont grosso modo 10 ans de retard sur ceux d'Hotspot car il n'y a pas les mêmes contraintes mémoires vu qu'on ne fait pas la même chose avec.
Dans ce thread y'a beaucoup de gens qui ne savent visiblement absolument pas de quoi ils parlent… Que ce soit la dessus ou en perf y'a des conneries vraiment halluciantes :/
[^] # Re: ça marchera jamais?
Posté par barmic . Évalué à 2.
Je connais mal dalvik, mais si dalvik utilise encore hotspot (ce que tu semble dire)¹ est-ce que ce temps a encore de l'importance ?
En principe tu n'arrête que rarement une application, elle se décharge. Dans ce cas là est-ce que la VM perd les compilations déjà effectuées ? Si ce n'est pas le cas le temps de chauffe peut se voir à la première utilisation de l'application uniquement.
¹ : je suis surpris parce que le bytecode n'est pas le même (dalvik n'est pas une JVM, elle utilise un bytecode à registre et pas à pile) donc à moins d'une grosse mise à jour sur hotspot je vois pas comment ils ont pu s'en servir.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: ça marchera jamais?
Posté par groumly . Évalué à 0.
Ou est ce que je dit que dalvik utilise hotspot?
Sinon, pour les perfs:
- tes applis se font tuer regulierement, des que ca manque de ram en fait
- le temps de demarrage d'une appli mobile est critique. Ios te tue apres 5 secondes, je considere perso plus de 750-800ms inacceptable sur mes applis.
Ya plein de techniques diverses et variees pour rendre le chargement plus rapide (qui tournentntoutes autour du lazy loading et du background processing), mais vu l'ordre de grandeur, et sachant que ya pas mal a faire entre le debut du main et la premiere run loop utilisable, ca laisse pas des masses de marge de manoeuvre.
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: ça marchera jamais?
Posté par barmic . Évalué à 1.
Quand on parle de temps de chauffe et de JVM on parle généralement d'hotspot.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: ça marchera jamais?
Posté par groumly . Évalué à 0.
Heu, ben ouais, pendant 10 ans c'etait un peu la seule jvm reellement utilisee, donc forcement, mais le temps de chauffe est plus lie au jit qu'autre chose.
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: ça marchera jamais?
Posté par ckyl . Évalué à 3.
Il y a quoi de spécifique à Hotspot ? Si tu gardes les mêmes contraintes qu'à HotSpot dans son cas d'utilisation classique (runtime important, byte code très con, JIT, viser la perf brute plutôt que les programmes à vie courte), je ne connais pas de VM avec un comportement différent.
Si tu veux changer ce comportement tu enlèves certaines de ces contraintes.
[^] # Re: ça marchera jamais?
Posté par barmic . Évalué à 2.
C'est là le tout. Je ne dis pas que hotspot est mauvais. Juste que le temps de chauffe viens du fait que la compilation optimisée va avoir lieu qu'après plusieurs passage sur le même bout de code. Mais lors de la création d'hotspot ce n'était pas une contrainte. Ils ont voulu garder un compilateur simple, personnellement ça ne me choque pas.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: ça marchera jamais?
Posté par devnewton 🍺 (site web personnel) . Évalué à 4.
J'ai fait quelques mesures sur mes projets après avoir lu ton commentaire:
Vu que je n'optimise pas (les optimisations prématures c'est la route du Mal et les optimisations matures finissent écrasées sur la route de la flemme par le camion du poil dans la main), le temps de chauffe et la consommation de RAM de la JVM ne me semble pas des obscacles insurmontables.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: ça marchera jamais?
Posté par cedric . Évalué à 1.
Chacun ses objectifs, mais 1.5s et 3s, c'est vraiment lent comme demarage. Tu sais pourquoi ca prend tant de temps ? Quels sont les specificites de ton systeme ?
Pour la RAM, c'est difficile a dire, si tu es sur un PC avec un jeu en resolution HD, tu vas deja perdre 11Mo pour le framebuffer. Maintenant, ca fait quand meme pas mal de chose que l'on peut mettre en 60Mo, dans quoi son repartit tes 60Mo ? Certain font tourner un compositeur graphique, un file manager en HD et un terminal avec autant de RAM…
[^] # Re: ça marchera jamais?
Posté par devnewton 🍺 (site web personnel) . Évalué à 2.
Pour nanimstudio je crois que c'est surtout le temps de chargement de swing. Pour Newton c'est plutôt le chargement de la musique et des textures de l'écran titre.
Lapin compris.
Difficile à dire, il y a la musique, les textures, le code…
Le message que je voulais faire passer, c'est que quand le but est de lancer un jeu sur une machine avec 4Go de RAM, quelques secondes au démarrage et quelques dizaines de mo, c'est négligeable.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: ça marchera jamais?
Posté par cedric . Évalué à 4.
My bad erreur de calcul. Si tu as un jeu en resolution HD celui-ci va prendre en memoire au moins 1920*1080*4 octets (environ 7Mo) si tu fais du rendu 2D. Avec DirectX ou OpenGL cela ne sera pas dans les statistiques de la memoire de ton process et ne se verra pas. En general, on fait du double buffer et donc ca sera probablement 14Mo, mais je ne sais pas comment marche la stack 2D de Java.
Personnellement, je trouve ca honteux qu'en 2013 on doive attendre plus longtemps pour le demarrage d'une application que pour le demarrage d'un OS complet. Je ne trouve qu'il n'y a rien de pire que les ecrans de chargement d'application. Un jeu qui est cense pousser au maximum le hardware qu'ils utilisent, certe, je veux bien accepter. Mais pour tout le reste, il n'y a pas d'excuse.
En 1s, tu as largement le temps d'afficher ta premiere frame et d'avoir une application utilisable. En demarrage a chaud (deja dans les caches disques), ca doit etre instantane, tu releves le doigt de la souris, que ton application est la ! Je ne vois pas comment on peut excuser un autre niveau de qualite.
Je ne fais pas la comparaison avec un environnement mobile ou il y a une plus grande integration et optimisation des composants de l'OS, mais il n'empeche que personne ne trouve acceptable d'attendre pour le lancement de son application qui a quasiment autant de feature que sur PC. Le multitache est limite par la memoire disponible, alors si toutes les applis prennent 60Mo lorsqu'elle pourrait en prendre 20 ou moins, et bien ton utilisateur va etre frustre d'avoir 3 fois moins d'application lance en parallele.
Je ne vois pas pourquoi cela devrait etre different sur PC. Je trouve insupportable que mon terminal prennent tellement de RAM que cela impact mes caches disques et ralentisse ma compilation. Je ne trouve pas acceptable le temps de demarrage de LibreOffice, ou celui de GIMP. Au final, utiliser Google Doc est plus rapide. C'est quand meme la honte qu'un service qui passe par des serveurs a l'autre bout du monde et un navigateur web se revele plus efficace que d'utiliser une application native…
[^] # Re: ça marchera jamais?
Posté par devnewton 🍺 (site web personnel) . Évalué à 1.
Si le jeu prends 2s, tu ne vas pas y jouer? L'important c'est le temps entre le lancement et le moment où tu joues, navigation dans les menus comprise. Avec Newton Adventure, tu joues en moins de 10s. Dans les "gros" jeux, cela va de 30s à plusieurs minutes. Sur ma machine, la palme revient à Crusader King où il faut 10 min avant de reprendre une partie…
Et celui de Firefox surtout! :-)
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: ça marchera jamais?
Posté par Zenitram (site web personnel) . Évalué à -2.
Tu es quand même en train de dire que ton jeu met plus de temps à démarrer qu'un OS entier (le mien en tous cas met quelques secondes à démarrer), c'est quand même sacrément la honte.
Désolé, mais non, ce n'est pas acceptable. En tant que testeur en 2013 (en 1990, j'attendais certes 20 minutes que la cassette finisse d'être lue…), c'est un point (attendre) qui n'est plus acceptable et qui donne une mauvaise impression initiale, surtout pour un "petit" (ça serait pour un jeu méga connu qui déchire en graphisme…) jeu.
[^] # Re: ça marchera jamais?
Posté par TImaniac (site web personnel) . Évalué à 3.
Euh, il n'y a pas relation entre le temps de démarrage de l'appli et le "temps de chauffe".
Le temps de chauffe correspond à la période pendant laquelle le code est interprété puis passe dans le JIT parc qu'identifié comme étant appelé régulièrement par la JVM : la "chauffe" continue donc après le démarrage "visible" par l'utilisateur.
Le temps de démarrage correspond plutôt au chargement par l'OS de la JVM, de ses bibliothèques, du programme à exécuter et de ses dépendances jusqu'à l'exécution du premier écran applicatif.
[^] # Re: ça marchera jamais?
Posté par ckyl . Évalué à 6.
Même pas vu que tout ce qui va être exécuté après l'écran de démarrage va être lazy loadé ;)
Je peux arriver à l'écran super rapidement et tout chargé après. Typiquement tu peux arriver à ton main en <50ms si il ne charge rien.
Ca dépend des options entre
-client,-serveretUseTieredCompilationpour HotSpotOh que oui. La chauffe peut même ralentir le code. Disons que ton code charge après 10 minutes une nouvelle classe. Hotspot va detecter que l'optimisation qu'il avait fait n'est plus valide (typiquement on peut transformer un appel virtuel en appel static si une seule implémentation) et bingo. Bon ca c'est pour l'annecdote ;)
En pratique on arrive au régime stable "assez rapidement" typiquement les micro-benchmark se stabilisent dans les 5/10 secondes. Passé 3 secondes, les gains restant sont généralement de l'ordre de 10-30%. Les macro bench prennent un poil plus selon la complexité du bordel et le tas de truc à charger (oui avoir 300 libs pesant 60Mo ca aide pas).
C'est ca qui coûte le plus cher à froid car le runtime est assez gros: ~1s avec les caches de la VMM vides, ~50ms avec les caches pleins.
Après on commence à charger les boûts de runtime non utilisés pas le bootstrap.
Dans l'ensemble la discussion est malheureusement assez inepte tellement elle est peu cadrée et sans référence. Pire encore des gens font comme moi et utilise des références desktop dans une discussion qui s'applique à un autre contexte.
[^] # Re: ça marchera jamais?
Posté par devnewton 🍺 (site web personnel) . Évalué à 3.
Des jeux toujours :-)
Dans ce cas le warm up time est négligeable, le chargement des données est largement plus long.
Les gc non deterministes sont un problème en effet, commun à Javascript et Java.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: ça marchera jamais?
Posté par groumly . Évalué à 0.
Dans le monde mobile, c'est surtout en train de perdre beaucoup de traction face a des sdk matures, flexibles, performants et qui ont au final une productivite bien superieure.
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: ça marchera jamais?
Posté par kursus_hc . Évalué à 6.
Quand je vois ce mot je pense à ma grand-mère en porte-jartelles. Si "mûr" ne sonne pas assez bien, on pourrait utiliser "abouti" ?
[^] # Re: ça marchera jamais?
Posté par groumly . Évalué à 5.
Clair que developer pour un framework ou un bouton est un fait un lien hypertexte qui ne pointe nullepart et a qui on a attache une gros kludge (onclick), ca fait rever.
De meme se taper le dom et ses perfs pourries, batailler contre css pour avoir deux divs cote a cote sans que ca pete des que t'eternues, ca donne super envie.
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: ça marchera jamais?
Posté par Laurent J (site web personnel, Mastodon) . É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 groumly . Évalué à 9.
Non, clairement pas raisonnable du tout. Les webeux vivent dans un monde parallele ou les perfs de chiottes sont acceptables, sortez votre tete du sable - une webview se remarque a des kilometres, ca met un temps fou a charger et a reagir.
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: ça marchera jamais?
Posté par claudex . Évalué à 1.
C'est valable sur iOS, sur Firefox OS, le navigateur est chargé en permanence, c'est beaucoup plus réactif.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: ça marchera jamais?
Posté par groumly . Évalué à 2.
Ca a pas grand chose a voir avec le fait d'avoir un navigateur charge ou pas.
Safari mobile se demerde admirablement bien, et ca reste super lent et pas reactif par rapport aux applis native, pre charge ou pas.
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: ça marchera jamais?
Posté par kursus_hc . Évalué à 2.
Tiens c'est marrant tout le monde n'est pas d'accord avec toi :
http://www.sencha.com/blog/the-making-of-fastbook-an-html5-love-story
[^] # Re: ça marchera jamais?
Posté par groumly . Évalué à 0.
tu confirmes ce que je dit, leur super prototype qui soit disant dechire sa race a l'air peu reactif et a un look de merde. Les rotations/transitions sont vraiments mauvaises (en fait, elles sont inexistantes), et bon courage pour implementer le "flick to exit fullscreen photo" de l'appli FB.
C'est en plein dans ce que je disais dans un autre message: les webeux vivent dans un monde parallele ou les perfs de merde sont une fatalite, et par la meme, acceptables.
Si c'est l'etat de l'art des applis riches html5, ben ca en dit long sur la qualite de la techno.
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: ça marchera jamais?
Posté par kursus_hc . Évalué à 10.
Tu as regardé la vidéo ou tu trolles ? L'app native et l'app html réagissent exactement de la même façon. Et si les transitions sont moins rapides, c'est un chiffre à changer dans les css.
Nul. Le design n'a rien a voir avec les perfs. Il n'y a pas de limites de design en css moderne.
HTML/CSS/JS a changé depuis la dernière fois que tu as dû en faire en 2002. Ca se code en 30 secondes.
Ben ça serait bien de ne pas passer sous silence les points qui ne t'arrangent pas, comme le "write once run everyhere" ou la compatibilité long terme. Reviens dans 15 ans avec un téléphone dernier cri et il y a de très fortes chances pour que ton app de 2013 fonctionne encore. Je ne crois pas qu'on puisse en dire autant pour le natif.
Juste pour clarifier je me fous comme de l'an 40 de cette fausse guéguerre, je tente juste de te faire réaliser que ton animosité est plus liée à ton ignorance qu'autre chose.
[^] # Re: ça marchera jamais?
Posté par groumly . Évalué à -10.
T'as tellement pas la moindre idee de ce dont tu parles que ca en devient pitoyable.
T'as perdu toute credibilite avec ton histoire de 30 secondes pour sortir du mode fullscreen - mon petit doigt me dit que t'as jamais vu la feature en question.
Pour ce qui est des transitions, tu dois avoir de la merde dans les yeux je me dit, et j'aimerais bien te voir gerer les rotations de facon fluide avec CSS, histoire de rigoler un bon coup.
Ouaiiiis, bien suuuuur. D'ailleurs, les effets de blurs qu'iOS7 introduits sont super simple a faire en CSS.
J'arrete la discussion a ce niveau - si des applis avec plusieurs dizaines/centaines de ms de reactivite et des animations saccadees (quand t'en as!) te conviennent, et que t'as tellement de la merde dans les yeux que t'es meme pas capable de t'en rendre compte, grand bien t'en fasse.
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: ça marchera jamais?
Posté par kursus_hc . Évalué à 6.
Bon déjà tu peux cesser d'être grossier et agressif, on n'est pas sur ton skyblog.
Ensuite si ce que tu cherches à dire est "plus le niveau du language est haut moins il est performant" ce n'est pas la peine de t'égosiller, tout le monde le sait déjà.
Si tu parles des rotations css encore une fois tu es de très mauvaise foi. Si tu parles des rotations portrait/paysage c'est plutôt bon signe que tu ne trouves que ça à redire.
Ca me rassure (encore une fois) de voir que ton seul argument est une fonctionnalité qui n'est pas encore sortie. Dommage que css sache faire ça depuis un an et demi :
http://net.tutsplus.com/tutorials/html-css-techniques/say-hello-to-css3-filters/
[^] # Re: ça marchera jamais?
Posté par groumly . Évalué à -6.
Ben visiblement t'as toujours pas compris quel est le coeur du problème - DOM et le manque de reactivite globale.
La vitesse est pas si importante, ce qui compte le plus c'est la latence, et HTML5/JS est un desastre a ce niveau la. D'autres trucs rentrent en compte, notamment les outils de debugging, mais ca c'est des trucs cote developeurs. HTML5/js n'est tout simplement pas capable a l'air actuelle de repondre au premier besoin de base - a savoir un truc qui est "snappy" et qui reagit sur le champ. Meme sur desktop, c'est border line, avec les monstres qu'on a de nos jours.
Ben voyons. En appliquant l'effet au background qui defile derriere? a 60FPS? J'aimerais bien voir ca tiens!
sinon, mes couilles sur ton nez, ca fait un skyblog?
Me traiter d'ignorant quand tu t'habilles visiblement chez Gucci Hot et que t'es pas foutu de voir des failles beantes d'UX, c'est pas de l'agressivité?
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: ça marchera jamais?
Posté par kursus_hc . Évalué à 5.
Ben oui maintenant que les différences sont presques invisibles.
Un désastre c'est clair, c'est le mot que je choisi à chaque fois que j'utilise une webapp. Et puis c'est vrai que toutes les apps natives sont hyper réactives. Encore une fois ces inconviénients sont liés à des avantages (sur lesquels tu n'as pas réagi d'ailleurs).
Ha oui tu as l'air de les utiliser souvent, tes arguments m'ont soufflé.
Ha complètement d'accord c'est le besoin fondamental pour une app, je reçois des milliers de retours utilisateurs par jour qui se plaignent d'avoir 5ms en trop de latence sur les clics.
Ha oui le flou en background à 60fps c'est énorme comme ça améliore la qualité de ton app. Pour moi c'est carrément le "second besoin de base" d'une app mobile.
Tu dois être bien malheureux pour être aussi méchant.
[^] # Re: ça marchera jamais?
Posté par groumly . Évalué à -5.
Ces deux phrases a elles seules resument ton ignorance crasse du "appli smarpthone grand public".
1) Personne ne te donnera jamais le moindre feedback sur ce genre de trucs, principalement parce qu'un bon design ne se remarque pas, a moins d'y faire tres attention et d'avoir des affinites avec la discipline. Par contre, quand tu mesure l'écart en A/B test, tu la voit la difference (et pas qu'un peu, on a un peu double la conversion depuis qu'on a commence a faire le choses decemment chez nous, et ya encore beaucoup de taff). Sinon j'ai envie de dire "mais je croyais que c'etait supporte depuis un an et demi que c'etait de la balle ya 30 minutes, et maintenant, tout d'un coup, ca devient completement inutile et superflu, une fois que tu te rends compte que c'est pas supporte"? Si c'est pas en ligne avec ce que je disais ailleurs, ou le HTML5 te limite fortement dans ce que tu peux faire, et que ses partisans acceptent ces limitations avec fatalité (autrement connu sous le nom de "j'suis trop flemmard pour faire mon taff correctemt eud'facons").
2) Cf 1. Ca rejoint ce que je disais, t'as des gouts de chiotte, et par du principe que le design visuel est de la connerie qui ne sert a rien. Ceux qui s'y sont essaye pour de vrai ont un autre avis.
Sur ca, j'arrete pour de bon. On vit sur differentes planetes toi et moi - visiblement ce qui compte le plus pour toi c'est que les developeurs en aient le moins a faire et torchent leur produit vite fait mal fait, et shipper est tout ce qui compte, meme si tu livres de la merde. Perso je shipe pas la merde, avec l'equipe on s'engueule toute la journee au sujet du meilleur design (mais le soir on va boire un godet ensemble).
Et au final, on met la tannee a l'equipe mobile web (meme avec les problematiques de deploiment et une semaine dans la vue en review sur le store), parce qu'on a un tooling et un framework de qualite. Et niveau conversion, on est tellement loin devant que c'est meme plus drôle.
On coute moins cher, pour un produit de meilleur qualite qui rapporte plus. Alors ton write once, kind of run everywhere but not really, hein…
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: ça marchera jamais?
Posté par kursus_hc . Évalué à 10.
Tu m'étonnes, tu as l'air d'être insupportable.
[^] # Re: ça marchera jamais?
Posté par zebra3 . Évalué à 3.
Remarque tout de même que passé le ton dérangeant, ses arguments se tiennent tout de même. Au moins on a l'impression de lire quelqu'un qui connaît son sujet.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: ça marchera jamais?
Posté par kursus_hc . Évalué à 6.
Oui ses arguments se tiennent, en bonne partie parce qu'ils ne sont pas contextualisés. Il précise quand même qu'il a "doublé la conversion" : en changeant quoi mystère. Si c'est lors d'une réécriture web>natif, j'imagine que l'appli web était bien pourrie, et qu'elle n'a pas été recodée à l'identique. On peu aussi "doubler sa conversion" en changeant la place ou la couleur d'un bouton, ça ne veut rien dire. On peut aussi mathématiquement doubler sa conversion en passant de 2 clics à 4. Bref sans le contexte (type, concurrence, volume, étendue, coût de dev, etc) on peut donner tous les arguments du monde.
Il oublie aussi de parler de la plateforme, argument que j'ai soulevé et sur lequel il n'a pas répondu : il y a fort à parier que son app est iOS only. Dans ce cas il est sûr que c'est mieux de faire du natif.
Si tu veux du natif multiplateforme, on va dire iOS/Android, ça commence à se restreindre un peu (je ne compte pas les coûts supplémentaires de dev), et si tu veux être clairement multiplateforme, il ne te reste que tes yeux pour pleurer. Je n'évoque même pas la question de la license du SDK.
Donc il connait son sujet mais il a tendance à le voir bien plus large qu'il ne l'est réellement.
Ha et aussi pour lui le point le plus important d'une app c'est la réactivité. Encore une fois hors contexte ça pourrait être vrai : 2 minutes d'attente à chaque action ça serait pénible. Dans le contexte c'est un peu n'imp, voir la vidéo postée au dessus.
Donc oui le natif c'est super, mais balayer d'un revers tout ce qui fait la force d'une webapp (universalité, pérennité) est carrément stupide.
[^] # Re: ça marchera jamais?
Posté par devnewton 🍺 (site web personnel) . Évalué à 2.
Pourquoi pérennité?
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: ça marchera jamais?
Posté par dave_null (site web personnel) . Évalué à 2.
HTML/JavaScript/CSS est rétro compatible. Un site web de 1998 ou de 2005 fonctionne toujours de la même façon aujourd'hui (modulo les hacks IE only de la sombre époque, phénomène qui a malheureusement tendance à revenir avec le webkit only).
On ne peut pas en dire autant de toutes les applications natives, car il faut s'adapter aux éventuelles évolutions imposées du langage (python 3 ?), des changements d'API, des mises à jours des dépendances…
[^] # Re: ça marchera jamais?
Posté par groumly . Évalué à 1.
Et les API rest/whatever derriere ton application HTML, elles sont retro compatibles elles?
On est plus en 2005, c'est plutot rare d'avoir une application qui marche a 100% sans réseau de nos jours.
Sans compter que vu le dynamisme du milieu, une appli qui n'est pas mise a jour au pire tous les 6 mois est une appli morte et enterree par les temps qui courent.
Ca va probablement changer, mais vu comment tout le monde reinvente l'industrie tous les 6 mois en ce moment, la perenite est loin d'etre le plus gros probleme. Le probleme en ce moment, c'est trouver des ingenieurs qui sont capable de faire les choses vite et bien - la plupart bossent sur iOS et sont plutot occupe.
On va dire que le chomage n'est pas quelque chose qui m'inquiete vu la gueule de ma boite linkedin cette derniere annee et la roadmap au taff.
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: ça marchera jamais?
Posté par Zenitram (site web personnel) . Évalué à -2.
Perso, je me frite assez souvent avec groumly, on est en désaccord et on le dit (presque version Linus :) ), et "malgré" (en fait "grace à") ça je n'hésiterai pas une seconde à aller boire un verre avec lui après (partie de la phrase que tu as omise, et qui invalide complètement ta remarque) car je vois très bien que les désaccords sont sur une vision qu'on a, mais que derrière il a un bagage technique / utilisateur qui poutre… Lui.
Après, certains préfèrent la forme au fond (pour une discussion mais pas pour une IHM, pas très logique mais bon, rien de nouveau).
[^] # Re: ça marchera jamais?
Posté par Zenitram (site web personnel) . Évalué à -1.
Cette seule phrase montre l'incompétence de la personne sur le design d'interface.
(si il faut être explicite : si tu attends des retours d'utilisateurs, tu peux toujours attendre, leur façon de faire est plutôt de prendre le concurrent, il faut que tu sois sur une niche non compétitive ou pour techos pour que les utilisateurs s'en foutent, sinon les utilisateurs ne vont pas s'emmerder à t'écrire, ils vont prendre le produit concurrent plus "sexy" en disant que ton produit est globalement nul à leurs potes dans les forums)
Si tu n'as pas de concurrents, peut-être. Mais ho bizarre, on n'est pas sur un marché minuscule comme Linux sur le desktop où tu peux te permettre de dire merde aux utilisateurs ils resteront quand même faute de mieux, et des concurrents sur les mobiles, il y en a à la pelle.
Ben oui, on n'est pas dans un repo d'une distro Linux qui te limite à une dizaine de milliers d'apps, l'utilisateur a le choix (un vrai choix, pas celui qu'on a sélectionné pour lui dans le repo) et utilise son pouvoir.
Mais bon, tout ça, c'est vraiment merdique, on se demande pourquoi d'ailleurs Mozilla passe une bonne partie de son temps à optimiser, à tester avec des utilisateurs (vu qu'il y a des millions d'utilisateurs, on se demande pourquoi ils s'emmerdent à organiser des tests avec d'autres utilisateurs). Sans doute parce que Mozilla a du succès, car… Ils ont sû écouter plus loin que des retours de mail.
Bref : on rigole bien sur les gens qui ne savent pas comment les utilisateurs qui ont le choix réagissent.
Tu te rends compte que tu demandes à l'autre en une phrase d'arrêter de faire ce que toi tu fais?
[^] # Re: ça marchera jamais?
Posté par kursus_hc . Évalué à 4. Dernière modification le 25 juillet 2013 à 15:10.
Non elle montre la tienne : 5ms est invisible à l'oeil nu.
Ben tu vois, tu les as tes retours utilisateurs.
Firefox est carrément moins réactif que Chrome et comme tu le dis toi-même ça ne l'empêche pas d'avoir des millions d'utilisateurs. Le gars dit quand même que le point le plus important d'une app est la réactivité, ce qui est complètement con : fonctionnalités, design, praticité, innovation, stabilité, rapidité, etc. sont donc des points moins importants.
Bref ça ne m'étonne pas que tu t'entendes bien avec lui : on parle d'un débat houleux qui dure depuis plusieurs années, chaque camps avec ses avantages, ses défauts et vraisemblablement aucune solution ultime, et le mec se pointe avec ses gros sabots en disant que ceux qui ne pensent pas comme lui sont des gros cons, balance deux ou trois poncifs fatalement vrais hors contexte en se la pétant genre il a codé la moitié des apps du top 10 iOS, et qu'il a trop raison et que c'est le roi français de l'UX, mais c'est ok car il connait son sujet.
[^] # Re: ça marchera jamais?
Posté par cedric . Évalué à 5.
Par contre, ca ne te laisse plus que 10ms avant que je le remarque :-)
Je me permet de donner ce lien a ce sujet: http://blog.kissmetrics.com/loading-time/ . Globalement le premier point important, c'est le temps avant la premiere frame (69% des gens s'attende a ce que le temps de chargement soit egal ou inferieur a celui d'un desktop). Pour ce qui est de la reactivite et de la capacite a delivre des animations a 60FPS, je pense que les utilisateurs peuvent supporter quelques frame drop, mais que la frustration apparait rapidement lorsque ca tombe sous les 30FPS trop souvent. Certain site web sont calamiteux de ce cote la et je ne les utilise pas. Par contre, je n'ai pas d'etude sur le sujet, donc je ne peux pas trop dire.
[^] # Re: ça marchera jamais?
Posté par groumly . Évalué à 1.
Bon, tu m'enerves et j'ai un peu de temps a perdre ce soir, alors je vais rempiler pour une couche.
Dans l'absolu, oui. Maintenant si 5ms en plus te font dropper une frame, je vais le voir, perso.
5ms, c'est 15% d'une run loop a 30fps.
Sur quelle planete tu vit? Perso, j'ai un taux de retour sur l'appstore inferieur a un pourcent. Et on est assez aggressif sur les "like this app? Rate it!". Et ca c'est sur le store, sur le web c'est encore pire, les gens bouncent et ne reviennent plus.
Et encore, faut savoir decrypter ce qu'ils disent ces gens, parce que la plupart racontent n'importe quoi (mais de bonne foi).
Si tu veux t'amuser a parcourir le web pour savoir ce que pensent moins d'1% de tes utilisateurs, libre a toi, perso j'ai autre chose a foutre.
Le seule truc pertinent, c'est les trackers qui te disent qui fait quoi quand, et en tirer des stats. Ca couvre 100% des gens, et c'est pas biaise par des emotions ou des problemes de communication. Par contre, c'est pas facile a lire/interpreter, mais au moins, ca ment pas.
Non, mais c'est une bonne partie de ce qui les a fait passe de roi du trottoir a suiveur qui perd des utilisateurs. Apres si passer de plus de 30% a 20% dans un marche qui stagne, voir decline, c'est avoir du succes je sais plus quoi dire.
Ce que j'ai dit c'est qu'html5 ne repond pas au besoin de base, et est donc exclu d'office de ma liste de technologies potentielles pour ecrire du code client.
Toujours est il que j'etais sur l'home screen des 2 dernieres keynotes (et probablement de la prochaine), ca me met dans un top 20.
Sinon,pour repondre a une de tes questions plus haut: non, on est pas ios only. Ios, android, blackberry (old school et new school), surface machin, mobile web, et il me semble qu'on etait aussi sur windows phone truc (celui d'avant le desastre actuel).
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: ça marchera jamais?
Posté par zebra3 . Évalué à 3.
C'est historique. Fx avait déjà des millions d'utilisateurs avant Chrome, mais toutes les études montrent que le second monte face au premier.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: ça marchera jamais?
Posté par karteum59 . Évalué à 5.
Pour l'avoir essayé (de même que ses concurrents): c'est marrant 5 minutes mais on ne joue clairement pas dans la même cour qu'Android ou Ubuntu (après, va savoir si ça vient du hardware bas de gamme ou de l'OS…).
Et du reste, il y a de bonnes raisons de penser que les applis web ne sont peut-être pas la meilleure approche pour les terminaux mobiles avec peu de RAM
[^] # Re: ça marchera jamais?
Posté par barmic . Évalué à 3.
Ça ne viens pas aussi de la jeunesse de l'ensemble ?
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: ça marchera jamais?
Posté par khivapia . Évalué à 1. Dernière modification le 23 juillet 2013 à 13:15.
Par rapport au lien que tu as donné, il critique surtout le modèle de gestion de mémoire par garbage collection, toutefois et précise que Mozilla semble consciente du problème et pousse très fort du côté de ASM.js : c'est un sous-ensemble du javascript, et pourrait être le langage de développement des applications des mozilla phones.
Ce le serait d'autant plus que Mozilla fournit un compilateur vers ASM.js à partir de langages à mémoire gérée à la main comme C ou C++ (emscripten), tel qu'il en existe depuis java vers javascript.
[^] # Re: ça marchera jamais?
Posté par khivapia . Évalué à 1.
De plus, la technologie de Mozilla semble prometteuse : cf http://blog.mozilla.org/mbest/2013/06/25/asm-js-its-really-fast-backwards-compatible-and-now-in-the-release-version-of-firefox/ par exemple. En tous cas, ils la vendent bien :-)
[^] # Re: ça marchera jamais?
Posté par Guillaume Denry (site web personnel) . Évalué à 6.
Pourquoi chercher à tout prix à faire tourner des applis "natives" dans un navigateur web sur un mobile plutôt que d'exécuter directement les applis natives ? Un truc m'échappe.
[^] # Re: ça marchera jamais?
Posté par claudex . Évalué à 7.
Parce qu'il y a déjà tout un système de sécurité de la VM existant pour JavaScript et que ce serait con de tout jeter pour le redévelopper. De plus, ça permet d'avoir des applications qui on le même rendu quel que soit le navigateur (sur un autre mobile ou un desktop).
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: ça marchera jamais?
Posté par barret benoit . Évalué à 1.
L'argument de l'interopérabilité me parle oui. Où en est la maturité de PhoneGap ?
[^] # Re: ça marchera jamais?
Posté par cedric . Évalué à 4.
Personnellement, ca me fait tres peur de pousser de plus en plus de fonctionnalite de securite dans une VM qui devient de plus en plus complexe. En gros, une JSVM devient son propre noyau sans avoir les separations entre les process. C'est je trouve bancale et ouvre la porte a pas mal de risque. Mais bon, c'est pas comme si mon Linux n'avait pas tout un tas de mecanisme de securite…
[^] # Re: ça marchera jamais?
Posté par khivapia . Évalué à 1.
Pour des raisons de sécurité, comme le dit Xavier Claude, ou pour avoir le même rendu partout.
Et puis parce que ça permet de s'abstraire de la plate-forme matérielle précise (type de processeur notamment) pour laquelle on développe ? Ou de tirer parti de toutes les possibilités du processeur en question (par le compilateur), sans devoir proposer un binaire différent ou des chemins de codes différents suivant les jeux d'instructions supportés.
[^] # Re: ça marchera jamais?
Posté par xcomcmdr . Évalué à 2. Dernière modification le 23 juillet 2013 à 17:17.
Hum, vraiment ?
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re:çamarchera jamais?
Posté par Juke (site web personnel) . Évalué à 2.
Y-a t-il une doc quelque part pour porter un logiciel ?
[^] # Re:çamarchera jamais?
Posté par barmic . Évalué à 2.
La spec est toujours en brouillon, il va falloir attendre.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: ça marchera jamais?
Posté par groumly . Évalué à 0.
Si j'ai bien suivi, asm.js est base sur une compile aot (sinon, j'ai du mal a voir l'interet).
Yen a vraiment qui pensent que c'est une bonne idee de retarder encore et encore le pageload quand c'est un des plus gros poblemes des sites mobiles?
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: ça marchera jamais?
Posté par barmic . Évalué à 4.
Hum, je ne comprends pas trop. Soit tu parle de la compilation d'un code en langage X vers asm.js, ça c'est fait manuellement par le développeur une bonne fois pour toute. Soit tu parle de l'exécution du code asm.js qui passe peut être (je sais pas) par une compilation vers du natif.
Si c'est ce dernier, le singe de Mozilla ne fait aucune différence entre du code asm.js et du code js écris à la main. Tous les langages de script aujourd'hui sauf le shell utilisent cette technique parce qu'on sest rendu compte que le temps de compilation et largement compensé par le gain en performance.
Je vois pas en quoi c'est une si mauvaise idée que ça.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: ça marchera jamais?
Posté par khivapia . Évalué à 2.
le singe de Mozilla ne fait aucune différence entre du code asm.js et du code js écris à la main
La seule mais énorme différence dans ce cas entre asm.js et du javascript écrit à la main est qu'il est possible de gérer la mémoire d'un code asm.js sans avoir besoin de garbage collector.
[^] # Re: ça marchera jamais?
Posté par cedric . Évalué à 2.
Ce que l'on peut reprocher a Firefox OS, d'exister principalement pour sauver la peau de Mozilla ! Dans un monde ou tout le monde se tourne vers le mobile, Firefox et Mozilla deviennent de moins en moins pertinent. Leur revenu va forcement diminuer au fur et a mesure qu'ils amenent moins d'utilisateur sur le net. L'alliance logique est aussi d'offrir un ecosysteme pour tous les developpeurs de site web qui ne peuvent pas faire un truc competitif avec les plateformes natives. En plus d'un appuie tres fort des operateurs qui ne savent rien faire d'autre que des technos Web. Avec l'alliances des trois, ils ont des developpeurs, une plateforme et un marche captif pour continuer d'amener des utilisateurs sur Internet et survivre.
Le probleme, c'est que la technologie est quand meme loin d'etre competitive avec Android ou Qt. Ce n'est pas forcement un modele d'ouverture (J'aimerais bien connaitre le rapport entre contribution paye par Mozilla et contribution libre exterieur). Il y a une augmentation de la complexite du systeme et des risques de securite non negligeable (Faire un navigateur web dans un navigateur web par exemple). De grosse difficulte de deboggage (j'inclus aussi traquer les problemes de consomation d'energie).
Maintenant la question est est-ce qu'il y a un marche pour un telephone moins bien que la concurrence. Les paris sont ouvert. La principale force de Firefox OS est de ne pas etre Android/Google et d'avoir le soutiens des operateurs. Faut voir si les operateurs sont toujours aussi fort et capable de faire manger n'importe quoi a leur client…
[^] # Re: ça marchera jamais?
Posté par claudex . Évalué à 1.
Pour le développeur, c'est quand même plus facile de faire une application pour Firefox OS que pour Android.
Qt Quick est loin de fournir les capacités de débuggage de Firefox (pouvoir inspecter le HTML aide énormément pour débugger une interface). Il se rapproche de la facilité de développement (avec certains côté plus récent que le JS et donc mieux fait) mais ce n'est pas équivalent.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: ça marchera jamais?
Posté par groumly . Évalué à 4.
Ouais, alors, ca, ca se discute.
Si tu veux faire un simple hello world, je veux bien te croire.
Si tu veux faire un truc un tant soit peu pas trivial, rapide, robuste (comprendre maintenable dans le temps), qui soit pas un monstre memoire ou qui ne mette pas un CPU haut de gamme a genoux, j'ai comme qui dirait de gros doute. Rien qu'a voir le temps que ca a prit aux gars du site mobile pour avoir un flyweight decent sur une table avec 1500 entrées, la ou les applis natives te font ca les doigts dans le nez, je suis sceptique.
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: ça marchera jamais?
Posté par Laurent J (site web personnel, Mastodon) . É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 cedric . Évalué à 4.
La question n'est pas de qui est le premier ou de si ca existe. Qui utilise encore des telephones sous Windows CE ? Le fait est que Firefox sur mobile a une base installe inferieur a 50 millions d'unites. Sur un marche de 1.5 milliard d'unite, ils sont tres loin des parts de marche du PC. C'est moins de 5%. C'est de mon point de vue pas pertinent.
Consomation d'energie, performance en multitache, tant de demarrage d'une application, … Si il suffisait d'avoir une masse de developpeur, Microsoft aurait reussi vu tous ces gens qui savent coder pour Windows ! Et Apple n'aurait jamais pu reussir, car il n'y avait pas de developpeur Objective C. Il va falloir reussir a les transformer en developpeurs d'applications mobiles… avec des utilisateurs au bout !
J'ai eu une experience tres mauvaise avec SpiderMonkey, ou globalement le developpement se faisait directement dans le code de Firefox puis quelqu'un decidait de faire un snapshot de ca et marquait pour release. Avec des decisions de casser l'ABI, l'API et plein d'autre joyeusete qui te tombe de haut sans aucune recherche de consensus. Sans compter que la qualite du code etait pas terrible, qu'on sentait les morceaux d'un certain age et les apports recent. Ca a peut etre change depuis…
Et Gecko est un morceau de code simple ? Ce n'est pas parce que tu fais une grosse boite que ca simplifie ce qu'il se trouve dedans. Tu y retrouves un bon paquet des boites exposes aux developpeurs dans Qt et Android.
C'est bien, c'est nouveau. En securite, j'aime bien les trucs qui ont fait leur preuve. L'isolation des process, la communication interprocessus, les droits d'access, …
Ca n'a pas l'air aussi trivial, la derniere fois que j'ai pu le tester dans Firefox OS, il etait pas en forme on va dire…
Va falloir les partager parce que les developpeurs de LinkedIn et Facebook ne sont pas au courant.
Vu les volumes de cette societe, ce n'est pas encore quelque chose qu'on peut mesurer. Ils en ont vendu combien ? 10.000 ? 100.000 ? Certainement pas un million. Ca reste encore faible et ca ne donne pas la taille du marche. Ca dit juste qu'il y a des developpeurs interresses, ce que je n'ai jamais conteste. Maintenant a l'usage on verra. Sans compter que je peux trouver un faux Galaxy S4 pour 120$ a Hong Kong (et pour le meme prix qu'un geeksphone, j'ai aussi un telephone Android vu que Firefox OS utilise comme base Android…).
Desole de t'avoir blesse, ce choix de mot n'etait pas opportun.
[^] # Re: ça marchera jamais?
Posté par claudex . Évalué à 7.
Pour Facebook, vu qu'ils n'arrivent pas à avoir une application réactive en Java, je ne suis pas sûr que ce soit la technologie le problème.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: ça marchera jamais?
Posté par zebra3 . Évalué à 5.
Quasiment pas, non.
Vu les perfs de merde, je me demande bien qui utilise Firefox sur Android. Sans déconner, il n'y a que lui qui rame autant, sans ouvrir de page, juste pour se lancer… Les gens de chez Mozilla ont vu ce que fait la concurrence ? C'est pas comparable du tout à Opera ou au navigateur par défaut.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: ça marchera jamais?
Posté par Kytrix . Évalué à 2.
Je ne suis pourtant pas sado-maso mais j'utilise Firefox Mobile !
c'est le navigateur principal de ma Neuxs7
je l'utilise en 2eme navigateur sur mon NexusS (très rarement)
Je l'utilise car je fais plus confiance à Mozilla pour la protection des données (avis subjectif je l'accorde)
je le synchronise avec la version de bureau pour la gestion des mots de passes.
[^] # Re: ça marchera jamais?
Posté par Laurent J (site web personnel, Mastodon) . É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 claudex . Évalué à 5.
J'ai un Firefox à jour et il met aussi plus de temps à charger que le navigateur Android. Je ne sais pas à quoi c'est dû mais j'ai l'impression que les performances de Firefox sont assez différentes sur les périphériques Android.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: ça marchera jamais?
Posté par zebra3 . Évalué à 3.
Je me réfère à ce que j'ai réussi à installer, c'est-à-dire la 21, la suivante n'étant pas disponible pour Android 2.3.
Ce que j'appelle des perfs de merde, c'est de devoir attendre 10 à 20s pour voir arriver l'interface, et même après elle est inutilisable car chaque action demande minimum 5s d'attente.
C'est vrai que mon téléphone et ma tablette sont sous Android 2.3 et n'ont que 256 Mo de RAM, mais faut pas croire que tout le monde a du matériel haut de gamme qu'il change chaque année comme les Galaxy. Et surtout Opera et le navigateur de base sont largement utilisables dessus.
Forcément après avoir vu ça, Firefox sur Android, c'est vraiment une blague.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: ça marchera jamais?
Posté par groumly . Évalué à 4.
2.65MB pour une appli avec une vue, une page html + js et toutes les librairies linkees?
J'ai le droit de dire que c'est de la triche et qu'il ya de la ram planquee quelque part?
Rien que le binaire fait probablement pas loin de 3MB…
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: ça marchera jamais?
Posté par dave_null (site web personnel) . Évalué à 3.
Il consomme moins de ram', et a pas mal d'extensions. Et une fois que tu supprimes la pub, ça va bien plus vite le web sur Android.
[^] # Re: ça marchera jamais?
Posté par zebra3 . Évalué à 3.
Le problème, c'est pas une histoire de mémoire, c'est que ça râme à mort. Vraiment. Ça met un temps fou à charger, et quand ça l'est, ça reste über lent.
Alors la conso' RAM, je m'en fous un peu. Ça ne me dérangerai pas qu'il consomme plus si ça pouvait le rendre utilisable avec un smartphone de base, chose que fait parfaitement Opera, encore une fois.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: ça marchera jamais?
Posté par dave_null (site web personnel) . Évalué à 2.
J'ai un smartphone 2 cœurs avec 512Mo de ram et une tablette quadricore avec 2go de ram et Firefox est rapide à se lancer et à fonctionner. Ce n'est pas parfait, mais je trouve Firefox légèrement plus réactif que Google Chrome ou le navigateur de base.
[^] # Re: ça marchera jamais?
Posté par Joris Dedieu (site web personnel) . Évalué à 9.
Du point de vue de la liberté, du respect de la vie privée et des standards c'est quand même l'OS mobile le plus avancé.
[^] # Re: ça marchera jamais?
Posté par cedric . Évalué à 3.
La derniere fois qu'on a parle de vie privee et de technologie du web, c'etait pas forcement une bonne chose ;-) Le plus grand challenge du "cloud" et des solutions html/js est bien maintenant de prouver quel respecte la vie privee. Mozilla l'a bien compris en s'engageant pour lutter contre PRISM, mais est-ce que ce n'est pas trop tard ?
Pour ce qui est des standards, je ne suis plus du tout convaincu que ce soit une bonne solution. Avoir une implementation unique construite sur le consensus de plusieurs societes me semblent bien plus efficace pour donner des resultats techniques. Il y a une tres grande difference entre developper un logiciel libre comme Qt et developper un standard comme HTML5. Je ne sais pas si vous avez deja assiste a ce genre d'exercice, mais dans un cas, c'est tres bureaucratique avec chacun veut pousser sa solution deja fini et forcer les autres a recoder, tandis que dans l'autre tout le monde travail a ameliorer une solution…
[^] # Re: ça marchera jamais?
Posté par claudex . Évalué à 4.
Et du coup, Qt réinvente les conteneurs standards et n'utilise pas les exceptions. Au final, Qt fait sa propre norme développée par Digia et c'est tout. Du côté du HTML5 chacun fait sa norme pour montrer que c'est possible et que ça ne pose pas de problème de sécurité et après ça, on choisi la meilleure.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: ça marchera jamais?
Posté par cedric . Évalué à 5.
Plus probablement celle qui a eu le plus de sufrage. C'est de la politique, pas de la technique.
[^] # Re: ça marchera jamais?
Posté par claudex . Évalué à 3.
Ta réflexion marche pour tout consensus. C'est tout aussi valable pour les technologies qu'on mets dans Qt, pour le standard C ou le noyau Linux (Linus inclut ce qui est demandé par les développeurs, sauf si ça pose des problèmes).
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: ça marchera jamais?
Posté par cedric . Évalué à 2.
La difference etant que le consensus se fait autour d'un morceau de code et pas autour d'un morceau de texte qu'il faudra transformer apres en code. L'un est plus facile que l'autre a evaluer sur son merite technique. Cela fait toute la differente !
[^] # Re: ça marchera jamais?
Posté par claudex . Évalué à 5.
Ce n'est pas le cas du standard C par exemple. C'est aussi à mettre à la poubelle ?
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: ça marchera jamais?
Posté par cedric . Évalué à 3.
Vu la vitesse a laquelle bouge le dit standard et vu les limitations de celui-ci…
[^] # Re: ça marchera jamais?
Posté par lasher . Évalué à 4.
Ce n'est pas bêtement dû au fait que la STL n'était pas présente à l'époque et qu'une fois que tu as tes propres conteneurs avec une certaine sémantique, c'est très chiant de tout recoder ?
Oui alors ça, c'est un argument assez faible je trouve. Doom 3 n'utilise pas les exceptions non plus…
[^] # Re: ça marchera jamais?
Posté par claudex . Évalué à 4.
Je n'ai pas dit qu'il n'y avait pas de bonne raisons de réécrire les conteneurs à une époque. Mais pour un développement moderne en C++, c'est chiant.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
# Pas encore trolldi mais
Posté par znk . Évalué à 0. Dernière modification le 22 juillet 2013 à 21:01.
Quel détail ! Ca changerai de la marque à la pomme. En sachant qu'un portable se tient plutôt à 1 ou 2m du sol, il faudrait le faire tomber combien pour finir avec un écran cassé ?
[^] # Re: Pas encore trolldi mais
Posté par deasy . Évalué à 1.
Je ne pense pas que saphir soit le bon mot…c'est plutôt un complexe avec de l'oxyde l'aluminium, matériau le plus dur après le diamant.
[^] # Re: Pas encore trolldi mais
Posté par ackernul . Évalué à 3.
Le saphir EST constitué d'oxyde d’aluminium.
http://fr.wikipedia.org/wiki/Saphir
[^] # Re: Pas encore trolldi mais
Posté par deasy . Évalué à 1. Dernière modification le 23 juillet 2013 à 00:40.
Cool merci mais je savais déjà.
Ce que je voulais dire c'est que c'est probablement qqchose à base d'oxyde d'aluminium un peu différent du saphir, donc pas du saphir.
[^] # Re: Pas encore trolldi mais
Posté par Marotte ⛧ . Évalué à 5.
http://fr.wikipedia.org/wiki/Saphir#Saphir_synth.C3.A9tique
Pourquoi ils parleraient de saphir si s'en était pas ? Pour l'image luxe & bling-bling ? :)
[^] # Re: Pas encore trolldi mais
Posté par case42 (site web personnel) . Évalué à 10.
Je dis pas que tu n'as pas raison, mais du coup, y a du vrai gorille dans le Gorilla Glass (tm) ?
[^] # Re: Pas encore trolldi mais
Posté par Marotte ⛧ . Évalué à 1.
Bien sûr que non, le gorille est une espèce protégée !
==> []
[^] # Re: Pas encore trolldi mais
Posté par deasy . Évalué à 1.
Exactement.
[^] # Re: Pas encore trolldi mais
Posté par bubar🦥 (site web personnel) . Évalué à -5.
Rien ne peux égaler la fragilité d'un Nexus fabriqué par LG :-/ Tombé de 40 cm sur le bitume, glace fêlée sur le coin haut droit uniquement : le tactile ne fonctionne plus… (à titre de comparaison un Nexus fabriqué par Samsung : fêlée en long en large et en travers, fonctionne toujours parfaitement bien)… LG, on ne m'y reprendra plus :-/
[^] # Re: Pas encore trolldi mais
Posté par Fabimaru (site web personnel) . Évalué à 10.
Étude réalisée sur un échantillon de 2 téléphones
[^] # Re: Pas encore trolldi mais
Posté par Pascal Terjan (site web personnel) . Évalué à 6.
A propos de Samsung je suis tombé sur http://www.youtube.com/watch?v=K4f9gQ7b6Gg il y a quelques jours, ils sont un peu violents :)
[^] # Re: Pas encore trolldi mais
Posté par Marotte ⛧ . Évalué à 6. Dernière modification le 23 juillet 2013 à 01:38.
Le saphir est dur ça veut dire qu'il résiste aux rayures, à l'abrasion, pas forcément aux chocs. Bref, à mon avis, en cas de chute de l'appareil ça doit être kif-kif avec un verre plus classique.
Sinon pour la taille maximale d'une vitre en saphir j'ai pas trouvé grand chose, juste ça :
http://en.wikipedia.org/wiki/Sapphire#Synthetic_sapphire
Ça à l'air tout à fait possible de faire une vitre carré de disons 20 cm de diagonale ?
# On le branche où on peut
Posté par julmx . Évalué à 2.
Ça sera génial quand les trains voitures, salons des amis, etc… seront tous équipés d'écran, claviers,souris. En attendant, je ne vois pas beaucoup de cas d'utilisation.
Je verrai un intérêt, si il existait un PC portable "vide" dans lequel on peut insérer le smartphone. Je crois qu'un constructeur avait tenté quelque chose dans le genre d'ailleurs, mais limité par un OS android, pas adapté à un PC. Après il ne faut pas que le prix soit supérieur à celui des deux appareils cumulé.
[^] # Re: On le branche où on peut
Posté par Naabster . Évalué à 3.
Il me semble qu'il s'agit du Asus Padpone
Sur le papier ce genre de produit donne envie.
# Open Hardware
Posté par akimatsumoto . Évalué à 10.
Une question non encore posée, le materiel sera il libre, ou a défaut, tournera il avec des pilotes libres ?
# Bon, mais alors, c'est libre?
Posté par small_duck (site web personnel) . Évalué à 10.
Pour moi, les grosses questions seront: est-ce que ce sera libre? Est-ce que je serai root dessus? Est-ce que je pourrai installer n'importe quel paquet Ubuntu? Et est-ce que Steam fournira des jeux?
Je me tâte vraiment à participer, mais c'était plutôt une tablette libre, que je voulais… (Vivaldi a l'air de bouger?)
# Trendeu myons ?!
Posté par Kerro . Évalué à -10.
J'ai bien lu 32 millions de dollars ?!
Sérieux, les devs sont payés en nature par des putes de luxe ?
[^] # Re: Trendeu myons ?!
Posté par manawy (site web personnel) . Évalué à 6.
Non, ce n'est pas étonnant du tout à mon avis. Il faut déjà compter l'installation de la chaîne de production qui doit pomper un bon petit paquet de fric. (C'est de l'électronique haute précision tout de même).
Et il faut voir que c'est un petit tirage pour l'instant, ils ne comptent pas sur les économies d'échelles.
Et le téléphone en lui_même est chère car a plutôt l'air de se situer dans le haut-de-gamme.
Ensuite, il faudra payer les devs, les designer (pas juste la boite, les composants a l'intérieur aussi), le marketing, les accords avec les compagnies de téléphones, l'achat des pièces détachés, l'usine…
Et peut-être que Marc espère enfin rentre son entreprise rentable…
[^] # Re: Trendeu myons ?!
Posté par Maclag . Évalué à 3.
Ouai mais là on ne parle plus du tout de la même chose.
Le financement, c'est pour développer un téléphone et lancer une petite série, ou pour construire sa propre usine?
Plus aucun fabricant de téléphone ne construit sa propre usine, et très peu paient le développement de la ligne de prod. Ils utilisent des sous-traitant, et ce sont ces usines d'assemblage qui doivent rivaliser pour proposer le meilleur de la techno au plus faible coût. Il y a une raison pour que même Apple préfère sous-traiter à Foxconn!
Et du coup j'aimerais bien savoir comment l'argent est utilisé exactement, sachant que Jolla, par exemple, a levé environ 10M$ et a déclaré avoir perdu 1.1M$ en 2012. Le coût des composants du téléphone influant assez peu sur le coût du développement, où passe la différence??
[^] # Re: Trendeu myons ?!
Posté par phyce . Évalué à 4.
A ma connaissance, mettre en place une chaine de prod coute cher (outillage, procédés, Q&A, …) et cela est généralement compensé par les volumes produits. Sur les petites séries, le cout unitaire de production explose et en plus le fabricant te demande un minimum d'unités produites (du genre tu t'engages à 100000 exemplaires)
Du coup pour produire ce genre de matériel haut de gamme en petites quantités c'est facturé très très cher pour canonical. Pour ne pas prendre de risque industriel, c'est les usagers qui avancent le fric…
[^] # Re: Trendeu myons ?!
Posté par cedric . Évalué à 10.
Non, c'est plutot realiste comme budget. C'est a peu pres ce que ca coute de developper un telephone. La partie la plus difficile dans la fabrication d'un telephone (ou d'ailleur de tout materiel hardware) est de sourcer les composants.
Quand tu t'appels Samsung, c'est facile, tu es gros et tout le monde veut te vendre un truc. Quand tu es petit, il te faut sortir une grande quantite de cash et payer d'embler pour 10000 ecrans pour en securiser l'approvisionnement. Et tu repetes l'histoire pour tous tes composants. Tu n'as encore rien produit et tes ingenieurs hardware travail pour l'instant sur un prototype avec des composants qu'ils esperent avoir que tu as deja depenser 80% du cout de ta BOM. Une fois que tous les composants sont la, tu essayes de valider un premier run. Si tu as de la chance, tu n'as pas de souci et tu peux continuer. En general, tu as des ajustement a faire et tu refais un tour. Dans le pire des cas, tu dois changer quelques composants et tu tentes de revendre ceux que tu ne veux pas utiliser.
A ce moment la, tu peux commencer a lancer ta production. Va falloir aller voir dans l'usine et verifier que ce qui sort est de qualite et passe les tests. La aussi, il y a de la perte et plus tu fais un truc cutting edge plus tes couts hardware vont monter. Meme si les materiaux choisi semble resistant, il est probable qu'il n'y ait pas d'usine qui ait l'habitude de travailler avec, donc des dechets sont a attendre. Il faut donc produire plus de telephone que ceux qui va etre vendu.
Au vu des specs du telephone et des volumes, il est probable que la BOM d'un tel telephone soit aux alentours de 400$. Tu as 10$ pour le cout d'assemblage, probablement une moyenne de 50$ pour la livraison international par Fedex, dhl, whatever. Le reste tu vas pouvoir le separer entre indiegogo, tes developpeurs, tes designers et le marketing. Pour simplifier, disons que Indiegogo prend 2m$ (7% du total). Il reste donc pour les modeles a 600$, 140$ par telephone et 370$ pour les modeles a 830$.
En faisant 40000 unites, avec 5000 a 600$, il reste 16 millions de dollar pour developper ton telephone. Le cout moyen d'un developeur est souvent estime entre 120000 et 150000$ par an. Ca donne donc de quoi payer aux alentours de 120 developpeurs sur un an. Comme il faut se laisser un peu de marge pour reinvestir et gerer la casse en cas de probleme, il est probable que cela couvre une centaine de personnes pendant un an… ou 50 pendant deux ans. Ce qui est a peu de chose les chiffres attendus pour le developpement d'un telephone (Jolla est a peu pret de la meme taille).
Et oui, faire un gadget, c'est pas gratuit !
# Mouai
Posté par benoar . Évalué à -5.
classique
Mouarf, quasi impossible ça, ça n'arrivera jamais.
classique
C'est beaucoup : c'est bien ! Mais pareil, ça n'est pas possible, ça prendre trop de place ou ça consommera trop d'énergie.
Mouarf, alors ça clairement impossible vu la taille des puces actuelles, si on veut que ça tienne dans un téléphone.
classique
Heureusement pour un téléphone “high-end” qui sort l'année prochaine.
Nanowire_battery truc jamais sorti du labo, impossible d'avoir ce genre de truc en place pour ce tél, et ça n'a même pas prouvé sa viabilité.
Et le CPU ? “Le plus rapide des quad core” ? Mais tout le monde fait pareil ! Et je parie une couille que ça sera du ImgTech en GPU, ou alors Nvidia peut-être, et du coup ça sera 100% proprio pour la partie graphique. Mais chez Ubuntu, ils sont habitués…
Je crois qu'ils font l'inverse, d'après ce qu'on avait déjà dit ici : ils ont une couche d'émulation Android. Par contre, avec le coup de la couche pour faire marcher leur serveur d'affichage (Mir ?) avec un driver Android (quasi-obligé vu ce qu'ils ont annoncé et le matos dispo), ça va faire de drôle de mélanges bien stables (soft proprio sur couche d'émulation qui utilise un driver proprio tournant sur une couche d'émulation…).
Et les morceaux priorios dedans ? On l'aura bien dans l'os.
Ah bah, avec les specs irréalistes en plus, je pense qu'ils ont joué le « plus c'est gros, plus ça passe » à fond !
Ça fait un bout de temps qu'ils font la quête, ça doit pas être la fête niveau finances en effet.
Bah, c'est moins risqué, c'est sûr.
+1
Bah si, quand même : théoriquement, il apporterait un vrai linux sur mobile. Ça, moi, c'est vraiment quelque chose qui me plaît. Mais un truc irréaliste avec plein de proprio dedans, ça n'est pas ce que je cherche par contre.
En fait, leur bordel, ça ressemble à ce qui faisait Nokia, et ils vont se planter pareil, mais en pire, ayant l'expertise hard en moins…
PS : faut que Mark arrête de copier Jonahtan Ive, par contre, ça se voit trop là, avec les superlatifs vagues dans tous les sens, mal rasé, etc.
[^] # Re: Mouai
Posté par Gui13 (site web personnel) . Évalué à -1.
Sur les SoC ARM la RAM est stackée sur le proc, et 4Go (16GB), ça n'existe pas encore.
Donc pour moi c'est du bluff.
Pareil pour la batterie et le verre Saphir. Le Saphir c'est 90€ le verre de montre, je veux même pas savoir ce que ça vaut pour un rectangle de 4,5 pouces de diagonale…
128Go me semble pas impossible, on a bien des clés USB qui le font.
[^] # Re: Mouai
Posté par claudex . Évalué à 6.
C'est 4Go, pas 16 (je ne comprends pas ce que tu veux dire par ça d'ailleurs), et c'est ce qu'il y aura dans le prochain Nexus 7, ça ne semble pas déraisonnable.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Mouai
Posté par Gui13 (site web personnel) . Évalué à 0. Dernière modification le 23 juillet 2013 à 10:26.
Les processeurs ARM multicores modernes sont à architecture stackée, càd que la RAM du processeur est empilée sur le(s) core(s) ARM dans un seul packaging.
C'est par exemple le cas du Raspberry Pi, du proc du Nexus 4, du Galaxy S4, de l'iPhone 5 et j'en passe.
Du coup, 4Giga octets = 16 Giga Bits
Je parle en terme de bits, puisque 1 bit de RAM nécessite un transistor et une capa, ce qui fait dans notre cas 32 Miliards de "transistors" à caser dans un chip. Ca n'existe pas aujourd'hui, donc je crie au bluff :)
[^] # Re: Mouai
Posté par Renault (site web personnel) . Évalué à 10.
Tu expliques comment 1 octet = 4 bits s'il te plaît ?
Par définition c'est 8…
[^] # Re: Mouai
Posté par Gui13 (site web personnel) . Évalué à 0.
Massive typo…. tu as bien évidemment raison! C'est 32Gbits, pas 16!
[^] # Re: Mouai
Posté par claudex . Évalué à 6.
Ça n'explique quand même pas pourquoi tu dis que c'est impossible alors que des tablettes avec 4Go de RAM, ça existe.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Mouai
Posté par Gui13 (site web personnel) . Évalué à 2.
Des tablettes à 4Go de RAM ça existe, oui, ça s'appelle des ordinateurs sans claviers…
C'est ce que tu trouves à la FNAC avec Windows 8, mais concrètement c'est une carte mère de pc portable.
La ram est alors de la DIMM standard, qui est soudée à côté du proc, alimentée par un étage de conversion de tension et tout…
Les tablettes Windows 8 sont pas du tout équipées de la même manière que les Windows RT et autres dérivés à base de ARM. Ca se ressent d'ailleurs au niveau de l'autonomie, une tablette en x86 dépasse pas les 4 ou 5h, comme un portable quoi…
Ici on parle d'un téléphone portable, qui a besoin au moins de 36h de veille, ce qui est impossible avec de la ram déportée et alimentée à part. La seule façon de garder une autonomie pas ridicule est de stacker, et une puce de RAM de 4Go ( 32Gb ) au format d'un processeur ARM, ça n'existe pas aujourd'hui à ma connaissance.
A moins qu'on m'aurait menti??
[^] # Re: Mouai
Posté par claudex . Évalué à 4.
Je ne savais pas que la nouvelle Nexus 7 tournait sous Windows 8.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Mouai
Posté par Gui13 (site web personnel) . Évalué à 3. Dernière modification le 24 juillet 2013 à 10:35.
Tain mais elle est même pas sortie ta Nexus 7 v2, c'est juste une rumeur que t'as lue sur FRAndroid et qui est tirée d'une photo leakée!
J'ai une Nexus 7 du mois dernier, et elle embarque 1Go de RAM pour le moment.
Alors ce soir (24 Juillet), peut-être, ils annonceront une V2 avec 4Go lors du "special event", mais c'est comme Ubuntu: tant que le hardware est pas là…
[^] # Re: Mouai
Posté par Gui13 (site web personnel) . Évalué à 2.
Et donc, j'avais raison…
La "nouvelle" nexus 7 a 2Go de Ram, pas 4Go….
http://www.pcinpact.com/news/81395-google-annonce-sa-nouvelle-nexus-7-sous-android-4-3.htm
[^] # Re: Mouai
Posté par Renault (site web personnel) . Évalué à 1.
D'un autre côté, si le téléphone de Canonical sort un jour, ce serait pour l'année prochaine où on s'en doute que ça va progresser au niveau finesse de gravure et taille des puces.
Si on suit la loi de Moore, les 2 Go ayant été atteint il y a un an pour la RAM des téléphone, il est possible d'avoir le double l'année prochaine sur une même surface.
Le Nexus 7 étant pour la fin du mois avec un développement entamé bien plus tôt, il ne peut pas bénéficier des dernières technos.
[^] # Re: Mouai
Posté par Zenitram (site web personnel) . Évalué à 1.
Samsung vient juste d'annoncer des stacks de 3 Go en disant bien qu'il va commencer par garder ça pour lui vu que les concurrents n'ont rien, alors à mon avis les 4 Go ne sont pas l'année prochaine comme ça, surtout pour un pauvre Canonical et 32 millions de $ qui font rire Samsung comme demandeur de telle puce.
[^] # Re: Mouai
Posté par Renault (site web personnel) . Évalué à 3.
L'article a précisé pourquoi Samsung se limite à 3 Go.
Les mémoires sont en général des puissances de deux pour une raison simple : niveau design, un quasi copié/collé du masque et du design de la puce suffit à doubler la capacité de la cellule mémoire, en en créant une deuxième équivalente. Si Samsung parvient à caser 3 Go dans une puce, ils sont en soit capable d'atteindre les 4 pratiquement immédiatement.
Le problème, outre celui du 32 bits d'adressage :
-Le prix de la puce, à avancer trop vite en technologie cela devient hors des prix acceptables pour l'acheteur
-L'intérêt, aujourd'hui les téléphones qui ont 1-2 Go sont trop rarement poussés à leurs limites car les applications n'exploitent pas encore une telle quantité d'espace, du coup passer directement à 4 Go serait du sur-dimensionnement au besoin actuel
En soit Canonical pourrait acheter les puces, même en faible quantité, le problème est toujours le même : le prix de la puce à l'unité et avec un faible volume il est clair que cela coûtera cher.
Personnellement je n'ai pas d'avis sur la réalisation de ce Ubuntu Edge, je dis juste que matériellement une puce de 4 Go de RAM pour téléphone en 2014 est quelque chose d'envisageable et cela semble le cas.
[^] # Re: Mouai
Posté par TImaniac (site web personnel) . Évalué à 2.
Y'a tout de même les tablettes à base d'x86 Atom, qui tournent plutôt autour de 8-10h d'autonomie. Ok en contrepartie on a les perfs d'un ARM mais il en faut pour tous les goûts :)
[^] # Re: Mouai
Posté par claudex . Évalué à 4.
Si ça n'existe pas, comment fait Google pour sortir la nexus 7 avec 4Go de ram ?
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Mouai
Posté par Zenitram (site web personnel) . Évalué à 6. Dernière modification le 23 juillet 2013 à 10:58.
D'une tu as mis "GB", et dans les normes B = byte (anglais) = octet (français).
Donc désolé mais 4 Go (c'est du français) = 4 GB (de l'anglais, on ne sait pas pourquoi, mais en français ça n'existe pas donc on cherche le cas le plus classique, et comme ce l'esperanto n'est pas classique (troll cf précédent journaux), on imagine plutôt l'anglais).
Tu voulais peut-être dire "Gb" ("b" voulant dire bit) mais comme 1 octet fait toujours 8 bits (ben oui), 4 Go = 32 Gb et non pas 16.
Donc j'avoue ne toujours pas comprendre cette idée de 4 Go = 16 GB, je ne trouve aucun lien (pas en français, pas en anglais, pas en bit/octets…)
Edit : argh, grillé, quelle idée d'écrire longuement et entre 2 choses…
[^] # Re: Mouai
Posté par Renault (site web personnel) . Évalué à 0. Dernière modification le 23 juillet 2013 à 11:03.
Non, Byte c'est la quantité d'informations la plus petite et qui adressable directement par le processeur.
C'est juste que dans la plupart des architectures actuelles, cette quantité est un octet donc dans certains cas en effet Byte = octet mais ce n'est pas vraie en général, ni par définition.
De mémoire les organismes de normalisation conseillent d'utiliser le terme octet (voire ioctet) au détriment de Byte pour lever ambiguïté.
[^] # Re: Mouai
Posté par Zenitram (site web personnel) . Évalué à 3.
Argh, fallait un tatillon pire que moi pour me faire la remarque :)
Pour meubler un peu, je dirai que de souvenir il y avait des bytes de 9 bits, mais jamais de byte de 4 bits, quelqu'un pour informer?
Et… comme bien traduire "byte" en français, avec la même chose générique (pas d'idée sur la taille du "byte")?
[^] # Re: Mouai
Posté par Renault (site web personnel) . Évalué à 3.
Les processeurs dans leur histoire ont globalement eu des byte de 1 à 9 bits, rarement plus. Le cas du 4 bits a existé (mais comme un octet c'est obligatoirement 8 bits, le poste de départ dit quoiqu’il arrive une connerie).
Pour traduire Byte en français il y a le terme multiplet qui semble exister. En tout cas Wikipédia et le Wikitionnaire en parlent.
[^] # Re: Mouai
Posté par imalip . Évalué à 2.
Il me semble que dans les DSP, avoir un mot de base de 32 bits est assez frequent. J'ai bosse sur de l'Analog Device TigerShark il y a quelques annees, chaque addresse contenant une valeur de 32 bits, c'est amusant a gerer…
[^] # Re: Mouai
Posté par TheBreton . Évalué à 2.
Voila la référence d'un processeur core 4 bits UPD17207GF avec lequel j'ai travaillé.
A l'époque on utilisait le terme "quartet" pour désigner le groupe de 4 bit et j'ai toujours utiliser "byte" pour 8 bits.
[^] # Re: Mouai
Posté par Romuald Delavergne . Évalué à 5.
Plus connu, il y a le processeur Saturn utilisé dans les calculatrice HP 48.
[^] # Re: Mouai
Posté par CrEv (site web personnel) . Évalué à 4.
Ce que c'était sympa ça :)
Enfin surtout les 49 sur lesquelles ont pouvait programmer en assembleur directement.
Bon en même temps il me reste toujours une 49 et une 48, je suis juste triste maintenant d'avoir vendu ma 48G dans laquelle j'avais soudé deux puces mémoires supplémentaires…
/le bon vieux temps
[^] # Re: Mouai
Posté par téthis . Évalué à 3.
Il existe sur hp48 des assembleurs permettant de convertir un fichier source asm en objet exécutable.
The capacity of the human mind for swallowing nonsense and spewing it forth in violent and repressive action has never yet been plumbed. -- Robert A. Heinlein
[^] # Re: Mouai
Posté par CrEv (site web personnel) . Évalué à 3.
Oui bien sur. C'est juste que c'était déjà fourni en standard lorsque tu avais une 49 ;-)
[^] # Re: Mouai
Posté par téthis . Évalué à 4.
Un byte n'a, à l'origine, pas de longueur définie. Avec la popularités des processeurs 8 bits, le byte est devenu synonyme d'un vecteur de 8 bits. Cette définition est restée depuis.
https://en.wikipedia.org/wiki/Byte
The capacity of the human mind for swallowing nonsense and spewing it forth in violent and repressive action has never yet been plumbed. -- Robert A. Heinlein
[^] # Re: Mouai
Posté par barmic . Évalué à 2.
Et à part peut être dans quelques labo, il existe une archi où ce n'est pas le cas ? L'ordinateur quantique probablement ?
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Mouai
Posté par Renault (site web personnel) . Évalué à 3.
Bah disons que dans l'embarqué et les systèmes industriels ce n'est pas rare de voir autre chose que l'octet pour un byte.
Sinon aussi, rien ne dit qu'à l'avenir on restera sur l'octet, peut être qu'on utilisera plus de bits…
C'est un problème que de considérer que comme aujourd'hui la différence est peu courante cela sera toujours vrai. Il vaut mieux garder la distinction car à l'avenir cela peut changer.
[^] # Re: Mouai
Posté par Zenitram (site web personnel) . Évalué à 3.
Bah… Ca n'a pas l'air de déranger foule de dire qu'un pixel ce n'est pas un pixel en fait (cf HTML "moderne" "px: pixel units — 1px is equal to 0.75pt.", quelle connerie de travestir les définitions comme ça… Un octet sera défini par "egal à 16 bits" un jour qui sait…)
[^] # Re: Mouai
Posté par Renault (site web personnel) . Évalué à 5.
Bah oui c'est en effet problématique de poser des définition pour ensuite leur donner un sens nouveau.
Mais une redéfinition de l'octet serait pire car la racine du mot fait référence à huit…
[^] # Re: Mouai
Posté par téthis . Évalué à 10.
Pour l'instant on à un mot pour ça. Le mot, c'est mot. Juste mot. C'est le mot juste. heu…
The capacity of the human mind for swallowing nonsense and spewing it forth in violent and repressive action has never yet been plumbed. -- Robert A. Heinlein
[^] # Re: Mouai
Posté par benoar . Évalué à 3.
Pas sur toute les archis, juste sur x86(-64).
Sur beaucoup de RISC 32 bits, un mot fait 32 bits…
[^] # Re: Mouai
Posté par lasher . Évalué à 3.
Ce n'est pas ce qu'il voulait dire je pense. Que ce soit en Anglais ou en Français, pour parler de la taille unitaire des données manipulables par un micro-processeur, on parle de « mot de
nbits ». Sur un DSP, que le proc travaille sur des mots de 16 ou 32 bits est extrêmement courant. Sur un PC, les mots de 32 ou 64 bits sont la norme; etc.[^] # Re: Mouai
Posté par téthis . Évalué à 4.
Les définitions en informatique bas niveau/électronique sont toujours foireuses et portent à confusion d'une génération à l'autre. D'mon temps, je programmais en asm sur processeur intel 32 bits et on nommait un champs de 16 bits un word et un de 32 bits un dword (ma vie).
Actuellement, lorsque je dois définir une longueur de variable dans un programme en embarqué, j'utilise la notation standard uint*_t ou int*_t aussi bien à l'oral qu'à l'écrit. Cela évite d'ajouter encore plus d'ambiguïtés car, entre les datasheets où chaque constructeur à ses coutumes et les habitudes de langages (vraies à un instant T, fausses à T + 1), on ne s'en sort plus.
The capacity of the human mind for swallowing nonsense and spewing it forth in violent and repressive action has never yet been plumbed. -- Robert A. Heinlein
[^] # Re: Mouai
Posté par lasher . Évalué à 3.
J'utilise
uint*_tlorsque je programme aussi. Mais je parle aussi de « mot de X bits », parce que c'est l'expression « correcte » pour décrire combien de bits sont manipulés à la fois. :) Du coup « byte » vaut TOUJOURS 8 bits dans notre contexte (vu qu'on utilise le terme « mot » sinon), ce qui arrange les choses.[^] # Re: Mouai
Posté par benoar . Évalué à 2.
Déjà, même cette définition n'est pas claire pour moi…
Bah, dit « n bits » tout court alors.
De mon côté, sur x86, un mot a toujours fait 16 bits, comme l'indique thétis. Sur PowerPC, un mot fait 32 bits. C'est décrit exactement comme ça dans ces ISA, et leur assembleur le reflète (un dword sur x86 c'est 32b, un hword sur PPC c'est 16b). Et tout ça, que ça soit sur 286 (16b), x86 (32b) ou x86-64, ou PPC (32b), ou PPC64.
[^] # Re: Mouai
Posté par lasher . Évalué à 2.
OK, je précise :
addl,addqgénérés par défaut pour (par exemple) les architectures x86_64. Dans le contexte du « vocabulaire » d'Intel c'est complètement logique.[^] # Re: Mouai
Posté par benoar . Évalué à 2.
Il n'y a pas que Intel qui respecte la compatibilité ascendante : sur PPC64, un mot fait 32b, parce qu'il faut rester compatible avec le PPC, et que l'archi « de base » a été créée pour du 32b.
Ce que je dis, c'est que les autres font exactement pareil, Intel n'est pas le seul, et « malheureusement » ces autres se sont basés sur leur taille de base à eux (et la plupart, c'était après, à l'époque où le 32 fleurissait, donc un mot c'est 32b chez beaucoup d'autres constructeurs qu'Intel ; OK, en volume, au final, ça ne représente pas tant que ça…).
OK. Alors je ne sais pas comment appeler ça, mais je rechignerais à l'appeler « mot », vu comment ça a déjà été utilisé pour autre choses sur les archis qui sont compatibles avec plusieurs « tailles » de GPR/adresse.
Bon, en gros on est à peu près d'accord, mais je pinaille un peu sur le vocabulaire. Je parlerais au final plus de taille de registre, ou de taille de pointeur, qui de taille de « mot ».
[^] # Re: Mouai
Posté par barmic . Évalué à 2.
C'est l'histoire des langues vivante ça.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Mouai
Posté par Zenitram (site web personnel) . Évalué à 1.
Pour le plaisir du troll vu qu'il y a de grands défenseurs de l'Esperanto dans le coin : mais ma bonne dame, ce n'est pas avec l'Esperanto que ce genre de chose arriverait, tout évolue super-bien sans aucune exception dans cette langue et personne ne ferait ce genre de modification horrible.
Bon, OK, facile de faire des théories sur l'évolution potentielle d'une langue morte ;-).
[^] # Re: Mouai
Posté par barmic . Évalué à 4.
Il faut aussi faire gaffe, je présume qu'il s'agit de 4 Gio ce qui fait un peu plus de 34 Gb.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Mouai
Posté par Gui13 (site web personnel) . Évalué à 0.
Wow j'ai complètement craqué… c'est bien évidemment 32Gbits qu'il faut lire… par 16!
[^] # Re: Mouai
Posté par Strash . Évalué à 10.
Ça existe déjà, c'est juste considéré comme trop cher pour l'instant. Dire que ça n'arrivera jamais, ça relève de l'incompréhension totale du monde moderne.
http://www.ldlc.com/fiche/PB00135011.html
Il me semble que c'est clairement possible.
Je m'arrêterais là, ton message essaie de démonter un produit qui est tout à fait faisable aujourd'hui. Je pense que tu aurais répondu un message similaire si Steve Jobs avait fait une vidéo 1 an avant la sortie de l'iPhone.
La technologie est là, le prix de fabrication est juste trop important pour un produit grand public.
Comme il le précise au début de la vidéo, c'est un produit dont le but n'est pas la voiture de Mr tout le monde, mais la F1. Soit un produit vitrine, fabriqué à perte, qui sert à vendre la marque.
[^] # Re: Mouai
Posté par deasy . Évalué à 1. Dernière modification le 23 juillet 2013 à 00:51.
Je plussoie la densité des puces a bien augmenté, c'est tout à fait possible de caser 128Go dedans et d'ici l'an prochain peut être même le double ou plus.
Les nouvelles puces gravées encore plus finement vont bientôt débarqué et vont encore avoir droit à une chutte du prix des SSD probablement.
Par contre…on attend encore les cycles garantis d'écriture…j'ai encore rien pour ça.
Bon sinon juste pour info là 23/07 00h50 1,922,150 déjà…ça avance vite
[^] # Re: Mouai
Posté par benoar . Évalué à -10.
Ah, tu m'as bien fait rigoler :-)
Qu'Apple annonce une vitre en saphir, et j'y croirai peut-être, mais Cannonical, heu…
Oui, avec un débit de 10Mo/s les jours de beau temps sur du gros séquentiel, et une endurance de 100 cycles. Dans un téléphone à 800 boules, ça va faire bien… Il y a une raison pour laquelle on ne trouve pas d'iPhone à 128Go, et la qualité de la NAND ça varie beaucoup.
Bah non, parce que Mark Shuttleworth n'est pas Steve Jobs…
Non. Ils font exprès d'annoncer des trucs impossibles pour faire rêver, mais ça n'est pas « là ».
« Fabriqué à perte »… tu vis chez les bisounours toi. Oui, ça sera fabriqué par des chinois exploités, mais sûrement pas à perte.
[^] # Re: Mouai
Posté par ʭ ☯ . Évalué à 10.
Tu veux dire qu'un des deux n'est pas encore mort?
⚓ À g'Auch TOUTE! http://afdgauch.online.fr
[^] # Re: Mouai
Posté par Zenitram (site web personnel) . Évalué à 1.
Une "F1" avec un pauvre écran 1280x720 dans 1 an (2 avec les retards) alors que les machines actuelles sortent en 1920x1080, j'éclate de rire.
L'année prochaine, 1280x720 sera l'écran du "pauvre", petites diagonales comprises.
[^] # Re: Mouai
Posté par barret benoit . Évalué à 2. Dernière modification le 23 juillet 2013 à 17:34.
Tu as raison quelque part.
Mais pas tout à fait, quand on voit que la résolution 1366x768 est la résolution "standard" depuis l'avènement du format 16:9 pour la majorité des écrans d'ordinateur portable 12 à 15,6 pouces…
[^] # Re: Mouai
Posté par Zenitram (site web personnel) . Évalué à 2.
Euh… J'avoue n'avoir jamais rencontré de téléphone portable (c'est ce dont on parle) de 12 pouces. Donc j'ai du mal à comprendre le "pas tout à fait".
Quand au PC portables (parents pauvres de l'évolution :( ), je tenterai l'idée que les écrans seront en 1920x1080 mini d'ici 1 an ou 2 (parce qu'avoir un PC portable moins précis qu'un téléphone portable, c'est un peu bizarre quand même).
[^] # Re: Mouai
Posté par patrick_g (site web personnel) . Évalué à 4.
Ce n'est pas ce que je comprends de cette phrase : "On day one, you’ll be able to launch the Ubuntu desktop from within Android using our existing Ubuntu for Android app."
[^] # Re: Mouai
Posté par Petit_Scarabee . Évalué à 1.
En fait en lisant le descriptif on comprend que c'est un dual-boot, donc on démarre Ubuntu touch ou Android.
Une fois le système démarré lorsque le tééphone est "docké" :
- sous androïd l'application Unbuntu for Androïd (qui existe déjà) est lancée pour avoir un bureau ubuntu en interaction avec le système Androïd (visualisation des appels, envoi et réception de sms, accès au carnet d'adresse…
- sous ubuntu touch : le bureau Ubuntu n'est pas encore disponible mais le sera rapidement après la sortie du téléphone grâce à une maj. Dans ce cas de figure pas d'androïd, ni en émulation ni en rien d'autre d'ailleurs, Androïd ne sera tout bonnement pas démarré et le téléphone sera "full ubuntu".
[^] # Re: Mouai
Posté par Fabimaru (site web personnel) . Évalué à 4.
J'ai un mini-ordi ARM Odroid. Le stockage (puce eMMC) de 64Go fait à peu près cette taille:
EMMC (image)
(c'est le composant sur la droite, on peut comparer la taille à celle du connecteur USB de l'antenne Wi-Fi à gauche)
[^] # Re: Mouai
Posté par benoar . Évalué à 1.
Bon, pas mal de commentaires sur cet aspect : allez voir la taille des composants dans un téléphone actuel, le Galaxy S4 par exemple, cf http://www.ifixit.com/Teardown/Samsung+Galaxy+S4+Teardown/13947/2#s46415
La puce fait 8mm de côté.
Et comme dit plus haut, des puces de merde (niveau débit ou endurance), il y en a plein, mais ça n'est pas ce qu'on met comme mémoire « fixe » d'un téléphone.
[^] # Re: Mouai
Posté par Kytrix . Évalué à 2.
alors en 2013 il existe des cartes MicroSD de 64Go, donc ce n'est pas avec l'encombrement de 2 cartes MicroSD que l'on va remplir ce téléphone.
Moi ce qui me dérange (hormis le prix et l'attente) ce sont les bords hyper épais :/
je ne suis pas fan des téléphones en métal, ça s'abime très vite, aucun intérêt en ce qui me concerne.
# vitesse crowdsourcing
Posté par xcomcmdr . Évalué à 3.
Ben ils en sont à 3 millions en 3 jours, c'est faisable.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: vitesse crowdsourcing
Posté par Dr BG (site web personnel) . Évalué à 5.
En un peu moins d'un jours non ?
Mais ça ne veut pas forcément dire grand chose. Ce genre d'annonce cartonne au démarrage, mais ralentit rapidement ensuite.
Je pense que ça va croitre plus lentement maintenant :
[^] # Re: vitesse crowdsourcing
Posté par patrick_g (site web personnel) . Évalué à 5.
Un graphe très intéressant tiré de ce post qui analyse les statistiques de plusieurs projets de crowdsourcing.
Au vu des courbes le ralentissement est quand même assez drastique.
[^] # Re: vitesse crowdsourcing
Posté par nicko . Évalué à 2.
Pour le suivi des projets kickstarter il existe http://www.kicktraq.com/. Je ne sais pas si il y a un équivalent pour indiegogo.
10% en moins d'un jour c'est plutôt encourageant.
[^] # Re: vitesse crowdsourcing
Posté par calandoa . Évalué à 4.
Suffit de demander : http://movebits.net/2013/07/23/ubuntu-edge-funding-level/
# Canonical fait avancer Linux.
Posté par Tanouky . Évalué à 9.
Je n'aime pas particulièrement Ubuntu, mais pour ma part, ils font progresser Linux, vraiment.
Pour ma part, Linux stagne pas mal dans son utilisation. On se retrouve avec des distributions à la pelle, mais le parti-pris n'intéresse finalement que peu de gens.
J'apprécie mes distributions (Archlinux et Debian), mais il faut bien avouer qu'elles sont vite limitées et qu'elles n'avancent à pas grand-chose, qu'elles ne font pas grandement progresser l'utilisation, les interfaces, etc.
Des projets et des idées, c'est ce qu'il faut, et à part Ubuntu, je ne vois pas grand-chose qui se profile à l'horizon.
"Le monde de Linux" est une vraie tortue. Ça avance certes sûrement, mais lentement.
[^] # Re: Canonical fait avancer Linux.
Posté par deasy . Évalué à -2. Dernière modification le 23 juillet 2013 à 15:45.
Non, elle essaye de se l'approprier, en terme de quantité de code Canonical n'est qu'un petit joueur.
Cette affirmation est fausse. De la progression par le brainwashing…
[^] # Re: Canonical fait avancer Linux.
Posté par Zenitram (site web personnel) . Évalué à 7.
On s'en fout de la quantité "petite".
L'important est la réponse au besoin.
Qu'on aime ou pas, il reste que Canonical a fait avancer largement plus le libre dans "les chaumières" que les autres (y compris Debian, sur lequel Ubuntu se base mais qui ne s’intéresse pas au desktop plus que pour les geeks soit pas grand monde)
Mais bon, ça ne change pas : critiquer celui qui a du succès car fait ce qu'il faut pour et se base sur un truc HS (genre la quantité de code) pour comparer. Le code ne fait pas tout, loin de la.
[^] # Re: Canonical fait avancer Linux.
Posté par Atem18 (site web personnel) . Évalué à 1.
Apple est le meilleur exemple qui me vienne en tête.
[^] # Re: Canonical fait avancer Linux.
Posté par deasy . Évalué à 1.
imho apple fait plus de code que canonical.
[^] # Re: Canonical fait avancer Linux.
Posté par Renault (site web personnel) . Évalué à 0.
Mouais. L’effort collectif a beaucoup aider Ubuntu aussi dont on ne citera pas le nombre d'améliorations que Ubuntu a pu profiter car les autres ont stabilisé et développé le bousin avant.
Je n'enlève pas le mérite à Ubuntu, dans le LL le code étant à disposition, c'est le jeu qu'ils le récupèrent pour un tirer un avantage comme le font d'autres distributions. Mais il ne faut pas oublier le travail important mener par les projet upstream et les distributions en elles mêmes comme Fedora qui ont aussi beaucoup apporté à la « réussite » relative de Ubuntu.
Canonical tout seul n'aurait jamais pu sortir Ubuntu, normal, cela aurait demandé bien trop de moyens.
[^] # Re: Canonical fait avancer Linux.
Posté par calandoa . Évalué à 10.
Personne au monde n'aurait jamais pu rien faire si leur Maman ne les avait pas mis au monde.
Il faut un petit peu arrêter avec la clause des licences libres qui stipule que si tu utilises un soft et que tu n'y contribues pas, tu es un sale petit minable de profiteur… clause qui n'existe que dans la tête des intégristes qui restent le cul sur leur chaise toute la journée à imposer leur conception de la liberté et s'imaginent que pointer du doigt autour d'eux des affreux imaginaires fait avancer le schmilblick (comme dans un certain journal il y a quelque jours).
[^] # Re: Canonical fait avancer Linux.
Posté par Renault (site web personnel) . Évalué à 3.
C'est bien ce que je dis, je dis juste que attribuer que la contribution la plus forte est de Canonical est sans doute une erreur. En soit j'ai dis exactement la même chose que toi…
[^] # Re: Canonical fait avancer Linux.
Posté par deasy . Évalué à -1. Dernière modification le 24 juillet 2013 à 16:23.
Tien ça me rappelle quelqu'un…qui reste assis sur une chaise et récolte le boulot d'autres et se l'attribue et récolte les louanges à tort du public…au hasard … Canonical.
Ils en branlent pas une désolé, niveau code c'est que dalle Canonical.
[^] # Re: Canonical fait avancer Linux.
Posté par Zenitram (site web personnel) . Évalué à 2. Dernière modification le 24 juillet 2013 à 16:35.
Tien ça me rappelle quelqu'un… Qui n'en branle pas une désolé, et en plus se permet de cracher sur ceux qui bossent et ont le malheur de mieux réussir que les autres.
Que ça te plaise ou pas, ça ne change pas que Canonical fait quelque chose, et pas qu'un peu.
Quitte à se répéter, ce n'est pas le nombre de lignes de code qui compte, mais la réponse au besoin (boulot largement plus utile que de faire des lignes de code, ce qu'oublient certaines personne qui mesurent par ligne de code), réfléchir un peu plus loin que la tête dans le code pour faire des choses utiles. Que ça plaise ou pas, c'est l'assemblage des bons composants qui fait un produit, pas faire bêtement un composant. Ben oui, c'est ça la grande valeur des outils. Tu minimises ce travail, en oubliant que les autres que tu dis "être écrasés par canonical" sont pas foutus de le faire, bizarre.
Oui, je sais, certaines personnes détestent les gens qui répondent au besoin, et éprouvent un besoin énorme de cracher dessus. Jalousie?
Euh… C'est pas le but du libre? Ah merde : le libre c'est pourri!!! Sans compter que c'est faux (Canonical code, même trop, il est critiqué pour ne pas assez réutiliser… Et la tu critiques qu'il réutilise trop, trop rigolo les attaques contradictoire, ça montre juste le n'importe quoi des gens qui crachent)
Source. En attendant, c'est de l'attaque gratuite de personnes détestant le succès, rien de plus.
J'avoue ne pas comprendre cette manie de cracher sur ceux qui ont du succès. Rien de nouveau certes, mais quand même, on pourrait évoluer un peu…
[^] # Re: Canonical fait avancer Linux.
Posté par deasy . Évalué à -2. Dernière modification le 24 juillet 2013 à 16:38.
QUand ils se réapproprieront les contrib via leur propre licence douteuse…je rigolerai bien des mêmes fanboys/adorateurs d'ubuntruc qui cracheront dessus parce que maintenant "canonical c'est un gros méchant pas bo"…alors que ça l'a toujours été.
[^] # Re: Canonical fait avancer Linux.
Posté par deasy . Évalué à -1. Dernière modification le 25 juillet 2013 à 02:41.
Ce que je veux dire c'est que faire louange d'Ubuntu c'est oublier le paquet du travail des autres à coté, largement supérieur à celui fait chez Canonical.
[^] # Re: Canonical fait avancer Linux.
Posté par Zenitram (site web personnel) . Évalué à 3.
Ce que je veux dire c'est que faire louange des autres à côté c'est oublier le paquet du travail de Canonical, largement plus utile (bon, la c'est surtout pour te paraphraser, car en fait il n'y a que toi qui veut absolument mettre des "supérieur" à tout prix) à celui fait chez les autres.
Tu confonds toujours quantité et qualité dans tes réponses, tu pourrais un minimum lire ce qu'écrivent les autres et adapter tes réponses. C'est certes classiquement un gros problème d'une assez grosse partie de la communauté Linux (ne pas aimer celui qui va réutiliser les briques techniquement bonnes mais inutilisables en pratique, et en faire un truc utilisable par le commun des mortels, et vouloir à tout prix descendre celui qui le fait), heureusement les mentalités (comprendre que la présentation est très très importante) évoluent (mais pas partout, encore des gens à parler de "largement supérieur" en passant pour frustré au niveau de l'égo, de temps en temps).
[^] # Re: Canonical fait avancer Linux.
Posté par zebra3 . Évalué à 7.
Mouais, il ne faut pas oublier les choses qu'on ne voit pas, genre sur la distrib server.
Par exemple, Canonical a fourni un immense boulot en intégrant AppAmor à Ubuntu et en est aujourd'hui le gros contributeur (AppArmor est sur Launchpad maintenant). Et tout ça s'est retrouvé dans Debian.
De plus, certains devs Canonical ont aussi pas mal bossé sur sa prise en charge de LXC, chose qu'aucune autre distribution n'a faite.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: Canonical fait avancer Linux.
Posté par xcomcmdr . Évalué à 10. Dernière modification le 23 juillet 2013 à 19:17.
N'oublie pas non plus le travail important de Canonical et de la communauté Ubuntu, qui a porté ses fruits : Ubuntu était tellement bien et tellement documentée qu'elle est devenu très populaire. Évidemment, dès que c'est populaire on crache dessus, mais rendre GNU/Linux populaire et noob-friendly n'est pas sans effets de bords bons pour le logiciel libre (exemple : on aurait Steam sous GNU/Linux, et les améliorations des pilotes graphiques qui ont suivi, si ça avait été juste une distribution connue par 3 personnes ?)
Beaucoup de projets libres ont démarré chez Canonical : LightDM (des développeurs KDE y ont même contribué), Ayatana, les application indicators, la police de caractères Ubuntu, Unity, …
Et énormément de monde a profité de Ubuntu : suffit de voir le nombre de variantes (officielles ou non), la popularisation des paquets .DEB, et les distributions basées sur Ubuntu.
Et puis, les membres de Canonical contribuent aussi au libre (exemple : LibreOffice [PDF], xfce4-volumed-pulse, Launchpad qui a été libéré, et j'en oublie énormément)
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Canonical fait avancer Linux.
Posté par saltimbanque (site web personnel) . Évalué à -1.
les stats me semblent amères: Ubuntu est né, a grimpé en flèche, et Linux a plafonné, voire reculé dans la même période.
Canonical a contribué a des trucs. Mais pas au succès de Linux, bien au contraire. Ubuntu ne peut répondre correctement au problème de trop de distrib dès lors que son but est très spécifique ; Kubuntu va bientôt mourir par exemple. Dès lors, tous les efforts fournis s'avèrent presque perdus à répondre à un besoin, or le "montant d'efforts disponibles" étant limité, ce sont autant de progrès en moins pour les autres.
Canonical a manqué tuer le bureau Linux avec une distribution qui a fini par lasser tout plein de dév
https://bugs.launchpad.net/ubuntu/+bug/1/comments/1834
[^] # Re: Canonical fait avancer Linux.
Posté par xcomcmdr . Évalué à 5. Dernière modification le 24 juillet 2013 à 00:47.
Sa sponsorisation par Blue Systems va s'arrêter ?
C'est un faux problème.
Je ne vois pas en quoi le montant d'efforts disponibles est au maximum de sa capacité. Le projet LibreOffice (par exemple) montre le contraire. Le kernel Linux le montre lui aussi régulièrement.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Canonical fait avancer Linux.
Posté par saltimbanque (site web personnel) . Évalué à 3.
Mir. Les dévs de KDE n'en veulent pas. Blue Systems sponsorisera toujours KDE qui sera toujours distribué… ailleurs. Et Qt continuera d'être actif dans l'embarqué, mais pas forcément que pour Edge.
ma phrase est très mal tournée c'est vrai. Je veux dire que "Ubuntu en tant que distribution potentiellement base de spins pour tous les bureaux", bref en tant que distro "normale", décline, au profit de Edge. Le produit Ubuntu se rapproche du produit Android - et s'éloigne de la distribution. Libre à Canonical ; j'employai le terme "problème" au sens où les utilisateurs de Linux sur le bureau ont encore besoin de distributions standard a-la-debian.
Contribuer à Ubuntu a pu signifier ne plus contribuer à Debian, etc… Or si Ubuntu vise un marché spécifique, cela fait moins de contrib pour les distro standard.
Projet qui a tant de succès car il est cross-platform. Le besoin d'une suite bureautique libre est tout autant pressant sur Windows et Mac.
Linux sert à tout. Mais la main d'oeuvre disponible pour Linux-sur-le-bureau est plus limitée ; les années précédentes, les mainteneurs Kubuntu auraient mieux fait de maintenir les paquets KDE pour d'autres distrib.
[^] # Re: Canonical fait avancer Linux.
Posté par Renault (site web personnel) . Évalué à 3.
Où J'enlève le mérite de Canonical dans l'histoire ?
Je remets juste en cause le fait que Canonical est en fait le plus gros contributeur, quand tu vois les efforts d'autres entreprises comme Redn Hat ou Novell sur de nombreux projets, on peut en douter.
Cela ne signifie pas que Canonical n'a rien fait.
On ne va pas faire la liste des projets Novell ou Red Hat qui en ont un paquet aussi (et souvent dans des couches plus basses, moins sexy mais nécessaires).
Bref je ne comprends pas cette volonté de dire ce que je n'ai pas dis.
[^] # Re: Canonical fait avancer Linux.
Posté par deasy . Évalué à -4. Dernière modification le 24 juillet 2013 à 16:20.
Oui bien sûr tu fais avancer les distro Linux sans code, sans modif, sans contrib :D
T'es un petit comique toi.
J'en ai un peu ras le cul de lire partout qu' Ubuntu fait avancer Linux…c'est totalement faux.
# Ça me semble effectivement très casse gueule
Posté par genesis83 . Évalué à 0.
Ca me semble effectivment très casse gueule : en cas d'échec cuisant de la campagne, bonjour pour aller démarcher les fabricants de smartphones pour y intégrer leur OS, surtout que ça n'a déjà pas l'air de se bousculer au portillon.
[^] # Re: Ça me semble effectivement très casse gueule
Posté par claudex . Évalué à 1.
À mon avis, c'est justement parce qu'ils n'ont trouvé personne qu'ils font cette campagne.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Ça me semble effectivement très casse gueule
Posté par Malizor . Évalué à 1.
Ba non.
Le Edge est un produit totalement à part qui n'a pas vocation à être commercialisé en dehors de cette campagne.
Les discussions avec les OEM sont toujours en cours. Et vu qu'ils ont le soutiens direct des plus gros opérateurs du monde, il est clair qu'il y aura des Ubuntu phone en 2014. Mais ces modèles seront forcément moins cutting edge que le Edge (et potentiellement lockés par les opérateurs).
(source)
Et même s'ils n'arrivent pas à lever les 32 millions, ça leur aura permis de se payer une bonne campagne de pub pour pas très cher. C'est vraiment tout bénef.
[^] # Re: Ça me semble effectivement très casse gueule
Posté par patrick_g (site web personnel) . Évalué à 4.
Le fait de ne pas atteindre un objectif c'est quand même pas super pour booster l'image de marque d'une société.
[^] # Re: Ça me semble effectivement très casse gueule
Posté par Marotte ⛧ . Évalué à 5. Dernière modification le 24 juillet 2013 à 23:54.
D'un autre côté : Ubuntu : « humanité envers les autres » et crowdfunding, c'est cohérent, pour leur image.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.