J'utilise aussi IE pour certains sites internes et les plantages sont monnaie courante, sans parler de la lourdeur (bon c'est IE8, le 10 est peut-être mieux).
Que les action non autorisées soient grisées, pourquoi pas, mais changer tout le temps de menu au fur et à mesure des actions, c'est anti-productif (Mais ou est ce bouton qui me permet de faire tel ou tel truc qu j'avais vu la semane dernière ? ).
Je trouve que tu démontres le contraire : tu vois d'un coup d'oeil toutes les actions que tu peux effectuer dans le contexte où tu es, tu cherches pas pendant 3h "ce bouton qui me permet de faire tel ou tel truc qu j'avais vu la semane dernière ? )." : il est devant toi.
Ca te permet également de découvrir des actions que tu n'aurais jamais eu l'idée de chercher/trouver avant : c'est un défaut récurrent mis en avant dans Office, le côté usine à gaz. Je trouve que c'est un moyen intelligent de faire découvrir les fonctionnalités à l'utilisateur.
Tout pour se perdre : imagine que tu cherches ton chemin pour aller à un endroit et qu'en route tout ce qui se passe autour change constamment : tu ne trouves plus ton chemin.
Comparaison totalement foireuse. Ton menu ne bouge pas d'un iota, tu ne peux pas être perdu. C'est plutôt une "prévisualisation", comme un "aperçu avant impression", pour éviter de choisir la mauvaise option puis annuler ton action. Faut vraiment être gonflé pour dire que celà est un inconvénient.
On s'en fiche du tactile sur un bureau de desktop.
Tu t'en fiches. Les outils évoluent, mon PC portable est tactile, même si j'ai l'habitude de la souris, quand elle n'est pas branchée (en déplacement toussa) c'est souvent plus agréable que le pad tactile. Sans parler des tablettes hybrides. Microsoft prend les devant et anticipe ces nouveaux usages. Que toi tu y sois réfractaire est une chose, mais je te fais le parie que LibreOffice y passera tôt ou tard.
Ben trouve moi un bon exemple. Pour le coup du PDF, c'est raté, c'était une fonctionnalité non présente de base dans Office 2010 (oui on peut se poser la question de la pertinence pour une suite sortie en 2009 de ne pas avoir d'export PDF par défaut mais c'est un autre débat).
J'ai vu, hier, quelqu'un dont le métier est de faire de la bureautique à longueur de journée, chercher pendant 5 bonnes minutes l'export pdf dans Word (quelque part à partir de 2010, je n'ai pas demandé la version).
Ca n'a aucun rapport avec l'ergonomie du ruban, juste que par défaut Office 2010 n'exportait pas en PDF, il fallait installer un "plugin". Après c'est simplement dans Fichier > enregistrer sous… puis choisir format "PDF".
Tant qu'à critiquer, autant prendre la dernière version hein. Alors Dans Office 2013, l'export PDF est dans… (vérifié sur 3 machines) Fichier > Exporter. Autre solution : Fichier > enregistrer sous… puis choisir format "PDF".
Woot super compliqué !
Bon après, je dois admettre que 75% de mon mécontentement est causé par Office lui-même.
Il est surtout causé par une bonne dose de mauvaise foi.
le format du paragraphe se trouve dans le menu Format/Paragraphe
Si je veu rajouter un champ/une image c'est dans Insertion/Champ ou Image.
bref on est dans le pragmatique l'utile l'efficace
vas y cherche sous Office 2010 :)
Ben le format du paragraphe est dans la section "Paragraphe", visible par défaut, et l'insertion d'une image est dans l'onglet "Insertion", "Image".
C'est quoi la différence ?
Tout le monde chie sur le ruban, je vois surtout celà comme des comportements bien réac de personnes qui ne supportent pas le changement. Pour moi le ruban apporte plusieurs choses sympa :
- contextuel : le ruban affiché dépend du contexte (création d'un tableau, modification d'une image, etc.)
- visuel : pas besoin de cliquer sur un menu grâce au mode contextuel, grosses icônes, adaptation à la largeur de l'écran. Survol des choix avec prévisualisation automatique des modifications.
- adapté au tactile : les boutons s'agrandissent dès qu'on est en tactile.
Je dirais que toi non plus ! On peut faire plein d'hypothèses "et si blablabla". Par contre il y a tout de même quelques certitudes :
- Aucun autre fabriquant n'a voulu mettre les pieds dans MeeGo.
- Intel a préférer laisser tomber le bouzin pour Tizen en partenariat avec Samsung.
- Tizen n'a toujours pas vu le jour commercialement sur un smartphone. Pourtant Samsung a tout intérêt à se démarquer de Google/Android.
Ca fait maintenant 2 ans, et toujours aucun bébé-meego sur le marché pour démontrer que cet OS est génial. Peut-être qu'il est pas si génial en fait ?
N9 pour MeeGo, 808 PureView pour Symbian. C'est quand même assez clair que derrière y'a qqun qui essayait de couler la boîte de l'intérieur…
Bof, tu démontres juste le point fort de Nokia : le hardware. Le N9 a été recyclé en Lumia 800 et le Pure View fait son retour à travers le Lumia 1020.
A un moment il faut faire des choix et te concentrer sur tes points forts. Maintenir un OS quand t'es tout seul à miser dessus, ca a un coût énorme. Apple se le permet parcqu'ils ont l'expérience, un marché bien spécifique (le haut de gamme) et les moyens (des milliards de pépète).
En ce qui concerne le conseil d'administration de Nokia, personne n'a compris leur comportement, ni comment ils ont fait pour valider les decisions de Elop.
TU ne comprends pas leur comportement. Ou plutôt TU ne les approuves pas.
N'empêche que leur stratégie n'a pas été aussi stupide que ça :
- leur OS n'était clairement pas taillé pour concurrencer les écosystèmes Android ou Apple, il fallait donc changer. Il y a avait 2 solutions : repartir à 0 ou partir sur un écosystème du marché.
- Blackberry a choisi de repartir à 0, on connaît la suite, ils sont au bord du gouffre avec des parts de marché en chute libre. Visiblement cette option est sacrément coûteuse et risquée.
- Choisir Android : ils ont choisis de ne pas rentrer en frontal face à Samsung. C'est assez logique, Samsung était en avance, celà aurait été dur de se démarquer : c'est pas les autres fabriquants qui contredirons ce choix : leurs parts de marché sont ridicules.
- Choisir un autre OS : visiblement aucun fabriquant n'a encore prouvé que c'était viable.
- Nokia a sans doute passer un deal très intéressant avec MS pour avoir une position d'intégrateur privilégié : résultat une marque Lumia qui a le vent en poupe, des parts de marché qui repartent à la hausse et qui commencent à titiller Apple.
Quand on achète un PC sans OS chez un fabriquant qui n'a pas l'idée de fournir les drivers au cas où t'installe un OS (on sait jamais), faut vraiment chercher la merde.
T'as fait le choix du radinou pour économiser le surcoût de 40€ que doit coûter la licence au constructeur, faut pas venir râler si le service derrière n'est pas au niveau.
J'ai dû réinstaller un portable de moins d'un an, aucun pilote fourni (même par la carte réseau…)
Euh, la quasi totalité des PC portable vendus depuis 3 ou 4 ans sont livrés avec une partition de restauration qui contient une image de l'OS avec les drivers intégrés. Tu as même parfois le CD fournis avec dans la boiboîte du PC.
Alors après effectivement, tu peux avoir supprimé cette partition, tu peux avoir perdu le CD de restauration, mais là c'est pas l'OS qu'il faut accuser hein.
Je confirme. Quand quelqu'un que je connais doit réinstaller son PC, c'est moi qui doit le faire parce que non il n'est pas capable de le faire tout seul, y compris les pilotes !
Problème grandement résolu avec Windows 8 : tu as une fonction "Tout supprimer et réinstaller Windows".
Dans ma catégorisation, cela reste donc avec une VM car le développeur ne distribue pas le résultat issu de la compilation à la volée, mais un "bytecode".
Sauf que le développeur peut tout à fait lancer le process manuellement grâce à une simple ligne de commande (ngen monprogramme.exe) : il peut le faire dans son setup par exemple, où sur sa machine de dev…
Si pour toi la notion de VM se limite à la façon dont le binaire est déployé, c'est vraiment une définition bien à toi :)
je fais malgré tout une distinction relativement simple : interprété / compilé à la volée -> VM
Sous Windows, .NET s'amuse à précompiler les programmes .NET en code natif et les garde en cache pour les prochaines exécution, il n'y a alors pas d'interprétation ou de compilation à la volée : .NET c'est avec ou sans VM alors ?
Quoi qu'il en soit, je sais que je vais regarder Qyoto de plus près d'ici peu. Car j'ai commencé à plancher un peu sur le problème et je rencontre déjà des problématiques que Qyoto doit déjà résoudre.
Franchement, ca me paraît beaucoup plus raisonnable que d'essayer de faire un nouveau truc qui mix C# et Qt : déjà qu'un binding c'est complexe, et tu gardes pourtant tous les outils existants des 2 mondes, mais une nouvelle plateforme from scratch où tout est à refaire…
L'objetif : que le bytecode soit le jeu d'instruction natif de la machine virtuelle… qui ne serait donc plus virtuelle !
Oui, virtuellement c'est faisable ;)
Ce que je voulais surtout mettre en évidence, c'est que tu ne dois pas te poser la question "VM ou compilé" : l'un décrit le modèle sur lequel s'appui le programmeur, l'autre une technique pour rendre le code exécutable.
A partir du moment où tu va vouloir reprendre le langage C# et ses principaux idiomes (async, lambda, linq, gc, securité), tu vas forcement devoir définir une VM. Après libre à toi de choisir une technique pour rendre le bousin exécutable.
L'intérêt n'est pas tant pour le programmeur C#. Il est plutôt pour les utilisateurs de Qt :)
Ok, donc l'objectif n'est plus de résoudre les problèmes de portabilité, pas non plus de proposer un nouveau Framework aux dev C# mais de proposer un nouveau langage aux dev Qt.
Bah fait un binding :)
Qyoto était pas si pourri, mais visiblement ca n'intéresse pas grand monde.
Et y'avait bien un mécanisme pour passer d'un event à un slot si je me réfère aux exemples par là : http://zetcode.com/gui/csharpqyoto/widgets/
Je m'abstiendrais donc de faire le moindre commentaire dessus et préfère attendre que tu me l'expliques :)
Une VM existe essentiellement sur le papier, par opposition à une machine "physique". D'où la présence de briques logiciels pour simuler le comportement de la VM sur une machine "physique".
Là, tu triches. Tu génères des problèmes de portabilités en utilisant, de base, une bibliothèque non portable, alors qu'à la base le problème vient d'une différence de comportement entre deux implémentations de la même API. Ce n'est absolument pas le même problème.
Disons que j'avais surtout aucune idée si ton problème venait d'un problème technique au niveau du serveur (IIS vs Apache) ou au niveau des API Nuget serveur que tu utilises.
Sympa la solution. Donc, on change l'implémentation par défaut sous Windows ?
Pourquoi ?
Mais quid des applications qui ne fonctionnement pas avec Mono ?
Bah justement : tu t'en fou. Comme avec ta solution : ne marcherons que les softs prévus pour marcher avec.
Ou alors faut-il demander à l'ouverture de chaque programme l'environnement à utiliser ? Celui de Microsoft ou celui de Mono ?
C'est au loader de l'OS de faire ce taf. T'as qu'à inventer une extension (.myexe) et l'associer à myruntime qui n'est qu'un raccourci vers mono si vraiment tu veux éviter toute confusion.
Mais pour le moment, il n'y a aucune implémentation de la solution que je propose et donc se focaliser sur ce type d'incompatibilités me semble limite hors sujet.
Ben c'est un peu l'objectif initial que t'affiche :)
C'est le problème de l'utilisation de Qt (car je trouve que c'est un excellent Framework) avec un langage ayant une syntaxe "légère" à la C# en opposition à la "lourdeur" du C++.
Ok. Donc maintenant : quel va être l'intérêt de Qt pour le programmeur C# habitué à son Framework de base ?
Ce qui serait bien, c'est que ce soit comme pour Ada. Pour qu'un compilateur puisse dire qu'il compile de l'Ada, il a tout une batterie de tests à passer.
Le problème ce n'est pas le langage : il y a une batterie de tests également pour C#. Le problème c'est les bibliothèques. Même avec toute les batteries de tests du monde, vu la taille et le nombre d'API, on ne peut passer à côté d'incompatibilités.
Il me semble que le projet Mono permette de compiler en code natif et de s'abstraire complètement de la VM. C'est d'ailleurs ainsi qu'ils peuvent compiler une application pour iPhone écrite en C# et la publier, puisque Apple interdit les VM.
Une VM est… virtuelle. Elle n'existe pas. Ce qui compte, c'est le comportement à l'exécution. Et là il existent pleins de techniques pour "simuler" le comportement de la VM : en général c'est un mix d'interprétation, de compilations et de bibliothèques de services (GC & co). Certaines VM se prêtent bien à des techniques de compilation à la volée, d'autres sont fortement limitées à l'interprétation.
La VM .NET sur laquelle s'appui C# a été conçu pour que techniquement on puisse compiler en code natif l'exécutable avant exécution, histoire de gagner du temps au démarrage (effet de bord : passer outre les restrictions Apple).
Le reste des services (GC, sécurité, introspection, etc.) est fournis par des bibliothèques qui sont chargées en même temps que le programme, comme c'est d'ailleurs le cas pour le C++ qui nécessite aussi une sorte de "runtime" pour certaines fonctionnalités (exceptions par exemple).
Donc oui, Mono fait de la compilation en code natif sur iPhone, .NET le fait aussi sous Windows et Mono sait aussi le faire sous Linux : c'est de la compilation Ahead-Of-Time (AOT).
Même dans le mode plus "classique" façon Java (Just-In-Time (JIT)), c'est le même processus qui se passe : compilation en code natif. La seule différence, c'est que dans un cas c'est fait avant l'exécution et l'autre pendant.
Qui génère des problèmes de portabilités. CQFD.
Super, et avec ta solution, je vais appeler une bibliothèque native de IIS, tu vas pas avoir le même problème pour porter ton appli sur Apache ?
Et c'est pourquoi je voudrais proposer une implémentation portable, qui ne nécessiterait pas une autre implémentation pour tenter d'assurer la portabilité
Si Mono existe, c'est aussi pour avoir une alternative sous licence "libre" : donc Mono se fait chier à recoder toutes les libs qui sont non-libres, même si elles sont techniquement portables.
En fait pour résoudre ton problème, t'as qu'à simplement ignorer l'implémentation de Microsoft : voilà, t'as Mono, c'est portable.
C'est vrai. Mais le fork est intrinsèquement lié au libre :)
Fork ou implémentation alternative, et t'auras exactement le même soucis que MS.NET/Mono.
C#/.NET est techniquement une plateforme portable. Les incompatibilités viennent de l'existance de plusieurs implémentations et de choix politiques/économiques de licences de diffusion. Tu résoudras pas ce soucis par une solution technique.
Dès qu'on souhaite appeler des bibliothèques natives, on se heurte à des problèmes de portabilités (et ceci, même si la dite bibliothèque est portable).
Je ne vois absolument pas en quoi t'appuyer sur Qt va t'aider à résoudre ce problème.
C# possède au contraire un des rares systèmes pour faire des appels à des bibliothèques natives de façon portable (sans glue façon java) grâce aux PInvoke : tu n'as même pas besoin de recompiler ton code managé qui appelle ta lib native. Evidemment ca suppose que ta lib soit effectivement portable à travers une interface C indépendante de la plateforme (ex : OpenGL).
langage compilé ou vm
C# est un langage compilé et nécessite obligatoirement une VM pour fonctionner : introspection, gestion de la mémoire, gestion des exceptions, etc.
Il peut même être précompilé en code natif avant exécution : les services de la VM sont toujours présents à l'exécution.
En fait ton problème, c'est pas la portabilité, ce sont des problèmes d'incompatibilité entre 2 implémentations. Dans ton exemple un problème de compatibilité entre Apache/Mono et IIS/.NET.
Créer une nouvelle plateforme (ce que tu proposes puisque ca ne sera pas 100% du C# ni 100% du Qt) est une fausse solution : si demain quelqu'un fork et que tu te retrouves avec 2 implémentations t'auras les mêmes soucis.
J'attends vraiment de voir ce que ca donne sur un téléphone plus puissant mais ca devrait fuser. Et ca c'est un vrai plus par rapport a Android et son java tout lourd et lent.
lol
Qu'on prône du C++ ou de l'Objective-C parcque Java c'est lent, c'est pertinent, mais mettre en avant une VM JavaScript à la place, c'est un brin abuser tout de même.
L'api Firefox OS a vocation a devenir un standard.
Un standard doit correspondre à une réalité industrielle, être utilisable et utilisé par la majorité des acteurs du secteur. Le W3C pond des standards parcqu'il est soutenu par Apple, Google, MS, etc.
C'est pas parcque Mozilla utilise les mêmes technos (HTML, CSS, JavaScript) qu'il va pouvoir prétendre que ses API spécifiques à Firefox OS sont des "standards" : ca sera des API propriétaires. Même combat pour Apache Cordova.
Windows Phone atteint tout de même 9% de PDM en France (prêt de la moitié d'iOS) et il est en progression constante. Tout l'inverse d'un BlackBerry qui va tout droit dans l'abysse des OS négligeables en terme de PDM aujourd'hui.
MS ne domine pas le marché, mais on peut dire qu'avec iOS et Android ce sont les seuls "qui comptent" à court terme.
La vrai question qu'il faut se poser, c'est en quoi Firefox OS ne va pas finir comme BlackBerry ? En quoi va-t-il se différencier des autres OS émergeants (Tizen pour ne pas le citer) ?
Si le seul argument c'est l'ouverture, même si c'est très séduisant pour nous libriste, 95% de la population s'en branle. On pourrait se dire "et alors, 5% ca nous va, du moment que c'est libre !". Le problème c'est que ce n'est pas un simple OS que l'on peut installer sur n'importe quelle machine comme une distri Linux : il faut s'assurer qu'il y est des fabricants de téléphone derrière qui suivent. Pas sûr qu'en leur promettant de s'attaquer à un potentiel de 5% de la population soit la meilleure façon de s'en assurer. Il faut donc avoir une logique identique aux autres OS et essayer de draguer le grand public pour espérer avoir des terminaux pour supporter l'OS.
BlackBerry se vautre parc qu'auprès du grand public il n'a à peu prêt rien qui le démarque de la concurrence : gamme de prix "haute", aspect matériel et logiciel "banale".
Firefox OS arrive après tout le monde, avec les mêmes "problèmes" d'aspect (pas de nouveauté sexy pour le public), des prix tirés vers le bas, mais pas suffisant pour dépasser Android. Bref, rien pour appâter le chaland. Même s'il affiche de nombreux partenaire matériel, Firefox OS n'a aucun poids lourd avec lui. Pire, le poids lourd Samsung qui aurait tout intérêt à miser sur une alternative à Google a choisi Tizen.
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.
, une tablette en x86 dépasse pas les 4 ou 5h, comme un portable quoi…
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: Tu es dur
Posté par TImaniac (site web personnel) . En réponse au journal MS Office c'est vraiment de la merde. Évalué à 1.
IE10 c'est largement amélioré à tous les niveaux. Niveau stabilité il est dans la moyenne :
http://www.theregister.co.uk/2013/08/20/firefox_top_marks_browser_stability/
[^] # Re: Tu es dur
Posté par TImaniac (site web personnel) . En réponse au journal MS Office c'est vraiment de la merde. Évalué à 0.
Je trouve que tu démontres le contraire : tu vois d'un coup d'oeil toutes les actions que tu peux effectuer dans le contexte où tu es, tu cherches pas pendant 3h "ce bouton qui me permet de faire tel ou tel truc qu j'avais vu la semane dernière ? )." : il est devant toi.
Ca te permet également de découvrir des actions que tu n'aurais jamais eu l'idée de chercher/trouver avant : c'est un défaut récurrent mis en avant dans Office, le côté usine à gaz. Je trouve que c'est un moyen intelligent de faire découvrir les fonctionnalités à l'utilisateur.
Comparaison totalement foireuse. Ton menu ne bouge pas d'un iota, tu ne peux pas être perdu. C'est plutôt une "prévisualisation", comme un "aperçu avant impression", pour éviter de choisir la mauvaise option puis annuler ton action. Faut vraiment être gonflé pour dire que celà est un inconvénient.
Tu t'en fiches. Les outils évoluent, mon PC portable est tactile, même si j'ai l'habitude de la souris, quand elle n'est pas branchée (en déplacement toussa) c'est souvent plus agréable que le pad tactile. Sans parler des tablettes hybrides. Microsoft prend les devant et anticipe ces nouveaux usages. Que toi tu y sois réfractaire est une chose, mais je te fais le parie que LibreOffice y passera tôt ou tard.
[^] # Re: Ergonomie
Posté par TImaniac (site web personnel) . En réponse au journal MS Office c'est vraiment de la merde. Évalué à 1.
Ben trouve moi un bon exemple. Pour le coup du PDF, c'est raté, c'était une fonctionnalité non présente de base dans Office 2010 (oui on peut se poser la question de la pertinence pour une suite sortie en 2009 de ne pas avoir d'export PDF par défaut mais c'est un autre débat).
[^] # Re: Ergonomie
Posté par TImaniac (site web personnel) . En réponse au journal MS Office c'est vraiment de la merde. Évalué à 1.
Comme quoi ca n'a strictement rien à voir avec le concept du ruban.
[^] # Re: Ergonomie
Posté par TImaniac (site web personnel) . En réponse au journal MS Office c'est vraiment de la merde. Évalué à 5.
Ca n'a aucun rapport avec l'ergonomie du ruban, juste que par défaut Office 2010 n'exportait pas en PDF, il fallait installer un "plugin". Après c'est simplement dans Fichier > enregistrer sous… puis choisir format "PDF".
Tant qu'à critiquer, autant prendre la dernière version hein. Alors Dans Office 2013, l'export PDF est dans… (vérifié sur 3 machines) Fichier > Exporter. Autre solution : Fichier > enregistrer sous… puis choisir format "PDF".
Woot super compliqué !
Il est surtout causé par une bonne dose de mauvaise foi.
[^] # Re: Tu es dur
Posté par TImaniac (site web personnel) . En réponse au journal MS Office c'est vraiment de la merde. Évalué à 3.
Ben le format du paragraphe est dans la section "Paragraphe", visible par défaut, et l'insertion d'une image est dans l'onglet "Insertion", "Image".
C'est quoi la différence ?
Tout le monde chie sur le ruban, je vois surtout celà comme des comportements bien réac de personnes qui ne supportent pas le changement. Pour moi le ruban apporte plusieurs choses sympa :
- contextuel : le ruban affiché dépend du contexte (création d'un tableau, modification d'une image, etc.)
- visuel : pas besoin de cliquer sur un menu grâce au mode contextuel, grosses icônes, adaptation à la largeur de l'écran. Survol des choix avec prévisualisation automatique des modifications.
- adapté au tactile : les boutons s'agrandissent dès qu'on est en tactile.
[^] # Re: et si... ?
Posté par TImaniac (site web personnel) . En réponse au journal La fin du Finlandais. Évalué à -5. Dernière modification le 03 septembre 2013 à 17:31.
Je dirais que toi non plus ! On peut faire plein d'hypothèses "et si blablabla". Par contre il y a tout de même quelques certitudes :
- Aucun autre fabriquant n'a voulu mettre les pieds dans MeeGo.
- Intel a préférer laisser tomber le bouzin pour Tizen en partenariat avec Samsung.
- Tizen n'a toujours pas vu le jour commercialement sur un smartphone. Pourtant Samsung a tout intérêt à se démarquer de Google/Android.
Ca fait maintenant 2 ans, et toujours aucun bébé-meego sur le marché pour démontrer que cet OS est génial. Peut-être qu'il est pas si génial en fait ?
[^] # Re: hum
Posté par TImaniac (site web personnel) . En réponse au journal La fin du Finlandais. Évalué à 0.
Bof, tu démontres juste le point fort de Nokia : le hardware. Le N9 a été recyclé en Lumia 800 et le Pure View fait son retour à travers le Lumia 1020.
A un moment il faut faire des choix et te concentrer sur tes points forts. Maintenir un OS quand t'es tout seul à miser dessus, ca a un coût énorme. Apple se le permet parcqu'ils ont l'expérience, un marché bien spécifique (le haut de gamme) et les moyens (des milliards de pépète).
[^] # Re: et si... ?
Posté par TImaniac (site web personnel) . En réponse au journal La fin du Finlandais. Évalué à 0.
TU ne comprends pas leur comportement. Ou plutôt TU ne les approuves pas.
N'empêche que leur stratégie n'a pas été aussi stupide que ça :
- leur OS n'était clairement pas taillé pour concurrencer les écosystèmes Android ou Apple, il fallait donc changer. Il y a avait 2 solutions : repartir à 0 ou partir sur un écosystème du marché.
- Blackberry a choisi de repartir à 0, on connaît la suite, ils sont au bord du gouffre avec des parts de marché en chute libre. Visiblement cette option est sacrément coûteuse et risquée.
- Choisir Android : ils ont choisis de ne pas rentrer en frontal face à Samsung. C'est assez logique, Samsung était en avance, celà aurait été dur de se démarquer : c'est pas les autres fabriquants qui contredirons ce choix : leurs parts de marché sont ridicules.
- Choisir un autre OS : visiblement aucun fabriquant n'a encore prouvé que c'était viable.
- Nokia a sans doute passer un deal très intéressant avec MS pour avoir une position d'intégrateur privilégié : résultat une marque Lumia qui a le vent en poupe, des parts de marché qui repartent à la hausse et qui commencent à titiller Apple.
[^] # Re: Madame Michu
Posté par TImaniac (site web personnel) . En réponse au journal De l'installation de Debian sur un Mabook Pro…. Évalué à 2.
Quand on achète un PC sans OS chez un fabriquant qui n'a pas l'idée de fournir les drivers au cas où t'installe un OS (on sait jamais), faut vraiment chercher la merde.
T'as fait le choix du radinou pour économiser le surcoût de 40€ que doit coûter la licence au constructeur, faut pas venir râler si le service derrière n'est pas au niveau.
[^] # Re: Autre question
Posté par TImaniac (site web personnel) . En réponse au journal La fin du Finlandais. Évalué à 0.
Réseau (Nokia Solutions and Networks) et cartographie (HERE).
C'est "encore" la moitié de leur chiffre d'affaire.
[^] # Re: Madame Michu
Posté par TImaniac (site web personnel) . En réponse au journal De l'installation de Debian sur un Mabook Pro…. Évalué à 1.
Euh, la quasi totalité des PC portable vendus depuis 3 ou 4 ans sont livrés avec une partition de restauration qui contient une image de l'OS avec les drivers intégrés. Tu as même parfois le CD fournis avec dans la boiboîte du PC.
Alors après effectivement, tu peux avoir supprimé cette partition, tu peux avoir perdu le CD de restauration, mais là c'est pas l'OS qu'il faut accuser hein.
Problème grandement résolu avec Windows 8 : tu as une fonction "Tout supprimer et réinstaller Windows".
[^] # Re: mouaich
Posté par TImaniac (site web personnel) . En réponse au journal Mélanger les syntaxes de C# et de Qt. Évalué à 2.
Sauf que le développeur peut tout à fait lancer le process manuellement grâce à une simple ligne de commande (ngen monprogramme.exe) : il peut le faire dans son setup par exemple, où sur sa machine de dev…
Si pour toi la notion de VM se limite à la façon dont le binaire est déployé, c'est vraiment une définition bien à toi :)
[^] # Re: mouaich
Posté par TImaniac (site web personnel) . En réponse au journal Mélanger les syntaxes de C# et de Qt. Évalué à 2.
Sous Windows, .NET s'amuse à précompiler les programmes .NET en code natif et les garde en cache pour les prochaines exécution, il n'y a alors pas d'interprétation ou de compilation à la volée : .NET c'est avec ou sans VM alors ?
Franchement, ca me paraît beaucoup plus raisonnable que d'essayer de faire un nouveau truc qui mix C# et Qt : déjà qu'un binding c'est complexe, et tu gardes pourtant tous les outils existants des 2 mondes, mais une nouvelle plateforme from scratch où tout est à refaire…
[^] # Re: mouaich
Posté par TImaniac (site web personnel) . En réponse au journal Mélanger les syntaxes de C# et de Qt. Évalué à 2.
Oui, virtuellement c'est faisable ;)
Ce que je voulais surtout mettre en évidence, c'est que tu ne dois pas te poser la question "VM ou compilé" : l'un décrit le modèle sur lequel s'appui le programmeur, l'autre une technique pour rendre le code exécutable.
A partir du moment où tu va vouloir reprendre le langage C# et ses principaux idiomes (async, lambda, linq, gc, securité), tu vas forcement devoir définir une VM. Après libre à toi de choisir une technique pour rendre le bousin exécutable.
Ok, donc l'objectif n'est plus de résoudre les problèmes de portabilité, pas non plus de proposer un nouveau Framework aux dev C# mais de proposer un nouveau langage aux dev Qt.
Bah fait un binding :)
Qyoto était pas si pourri, mais visiblement ca n'intéresse pas grand monde.
Et y'avait bien un mécanisme pour passer d'un event à un slot si je me réfère aux exemples par là :
http://zetcode.com/gui/csharpqyoto/widgets/
[^] # Re: mouaich
Posté par TImaniac (site web personnel) . En réponse au journal Mélanger les syntaxes de C# et de Qt. Évalué à 2.
Une VM existe essentiellement sur le papier, par opposition à une machine "physique". D'où la présence de briques logiciels pour simuler le comportement de la VM sur une machine "physique".
Disons que j'avais surtout aucune idée si ton problème venait d'un problème technique au niveau du serveur (IIS vs Apache) ou au niveau des API Nuget serveur que tu utilises.
Pourquoi ?
Bah justement : tu t'en fou. Comme avec ta solution : ne marcherons que les softs prévus pour marcher avec.
C'est au loader de l'OS de faire ce taf. T'as qu'à inventer une extension (.myexe) et l'associer à myruntime qui n'est qu'un raccourci vers mono si vraiment tu veux éviter toute confusion.
Ben c'est un peu l'objectif initial que t'affiche :)
Ok. Donc maintenant : quel va être l'intérêt de Qt pour le programmeur C# habitué à son Framework de base ?
[^] # Re: mouaich
Posté par TImaniac (site web personnel) . En réponse au journal Mélanger les syntaxes de C# et de Qt. Évalué à 7.
Le problème ce n'est pas le langage : il y a une batterie de tests également pour C#. Le problème c'est les bibliothèques. Même avec toute les batteries de tests du monde, vu la taille et le nombre d'API, on ne peut passer à côté d'incompatibilités.
Une VM est… virtuelle. Elle n'existe pas. Ce qui compte, c'est le comportement à l'exécution. Et là il existent pleins de techniques pour "simuler" le comportement de la VM : en général c'est un mix d'interprétation, de compilations et de bibliothèques de services (GC & co). Certaines VM se prêtent bien à des techniques de compilation à la volée, d'autres sont fortement limitées à l'interprétation.
La VM .NET sur laquelle s'appui C# a été conçu pour que techniquement on puisse compiler en code natif l'exécutable avant exécution, histoire de gagner du temps au démarrage (effet de bord : passer outre les restrictions Apple).
Le reste des services (GC, sécurité, introspection, etc.) est fournis par des bibliothèques qui sont chargées en même temps que le programme, comme c'est d'ailleurs le cas pour le C++ qui nécessite aussi une sorte de "runtime" pour certaines fonctionnalités (exceptions par exemple).
Donc oui, Mono fait de la compilation en code natif sur iPhone, .NET le fait aussi sous Windows et Mono sait aussi le faire sous Linux : c'est de la compilation Ahead-Of-Time (AOT).
Même dans le mode plus "classique" façon Java (Just-In-Time (JIT)), c'est le même processus qui se passe : compilation en code natif. La seule différence, c'est que dans un cas c'est fait avant l'exécution et l'autre pendant.
Super, et avec ta solution, je vais appeler une bibliothèque native de IIS, tu vas pas avoir le même problème pour porter ton appli sur Apache ?
Si Mono existe, c'est aussi pour avoir une alternative sous licence "libre" : donc Mono se fait chier à recoder toutes les libs qui sont non-libres, même si elles sont techniquement portables.
En fait pour résoudre ton problème, t'as qu'à simplement ignorer l'implémentation de Microsoft : voilà, t'as Mono, c'est portable.
Fork ou implémentation alternative, et t'auras exactement le même soucis que MS.NET/Mono.
C#/.NET est techniquement une plateforme portable. Les incompatibilités viennent de l'existance de plusieurs implémentations et de choix politiques/économiques de licences de diffusion. Tu résoudras pas ce soucis par une solution technique.
# mouaich
Posté par TImaniac (site web personnel) . En réponse au journal Mélanger les syntaxes de C# et de Qt. Évalué à 5.
Je ne vois absolument pas en quoi t'appuyer sur Qt va t'aider à résoudre ce problème.
C# possède au contraire un des rares systèmes pour faire des appels à des bibliothèques natives de façon portable (sans glue façon java) grâce aux PInvoke : tu n'as même pas besoin de recompiler ton code managé qui appelle ta lib native. Evidemment ca suppose que ta lib soit effectivement portable à travers une interface C indépendante de la plateforme (ex : OpenGL).
C# est un langage compilé et nécessite obligatoirement une VM pour fonctionner : introspection, gestion de la mémoire, gestion des exceptions, etc.
Il peut même être précompilé en code natif avant exécution : les services de la VM sont toujours présents à l'exécution.
En fait ton problème, c'est pas la portabilité, ce sont des problèmes d'incompatibilité entre 2 implémentations. Dans ton exemple un problème de compatibilité entre Apache/Mono et IIS/.NET.
Créer une nouvelle plateforme (ce que tu proposes puisque ca ne sera pas 100% du C# ni 100% du Qt) est une fausse solution : si demain quelqu'un fork et que tu te retrouves avec 2 implémentations t'auras les mêmes soucis.
[^] # Re: Bon courage
Posté par TImaniac (site web personnel) . En réponse à la dépêche Firefox OS est lancé. Évalué à 10.
lol
Qu'on prône du C++ ou de l'Objective-C parcque Java c'est lent, c'est pertinent, mais mettre en avant une VM JavaScript à la place, c'est un brin abuser tout de même.
http://benchmarksgame.alioth.debian.org/u64/benchmark.php?test=all&lang=v8&lang2=java&data=u64
Et encore c'est un bench "mono-core", visiblement ils n'ont pas fait l'affront de bencher V8 sur une machine multi-core, ca aurait été un massacre.
[^] # Re: http://xkcd.com/927/
Posté par TImaniac (site web personnel) . En réponse à la dépêche Firefox OS est lancé. Évalué à 9.
Euh, je crois que tu n'as jamais regardé ce que proposait BlackBerry pour tenter de séduire les développeurs :
https://developer.blackberry.com/platforms/
Bref, dragguer les développeurs ca ne suffit pas. Faut commencer par dragguer les utilisateurs et les constructeurs.
[^] # Re: Le lien xkcd n'est pas pertinent
Posté par TImaniac (site web personnel) . En réponse à la dépêche Firefox OS est lancé. Évalué à 4.
Un standard doit correspondre à une réalité industrielle, être utilisable et utilisé par la majorité des acteurs du secteur. Le W3C pond des standards parcqu'il est soutenu par Apple, Google, MS, etc.
C'est pas parcque Mozilla utilise les mêmes technos (HTML, CSS, JavaScript) qu'il va pouvoir prétendre que ses API spécifiques à Firefox OS sont des "standards" : ca sera des API propriétaires. Même combat pour Apache Cordova.
[^] # Re: http://xkcd.com/927/
Posté par TImaniac (site web personnel) . En réponse à la dépêche Firefox OS est lancé. Évalué à 5.
Windows Phone atteint tout de même 9% de PDM en France (prêt de la moitié d'iOS) et il est en progression constante. Tout l'inverse d'un BlackBerry qui va tout droit dans l'abysse des OS négligeables en terme de PDM aujourd'hui.
MS ne domine pas le marché, mais on peut dire qu'avec iOS et Android ce sont les seuls "qui comptent" à court terme.
La vrai question qu'il faut se poser, c'est en quoi Firefox OS ne va pas finir comme BlackBerry ? En quoi va-t-il se différencier des autres OS émergeants (Tizen pour ne pas le citer) ?
Si le seul argument c'est l'ouverture, même si c'est très séduisant pour nous libriste, 95% de la population s'en branle. On pourrait se dire "et alors, 5% ca nous va, du moment que c'est libre !". Le problème c'est que ce n'est pas un simple OS que l'on peut installer sur n'importe quelle machine comme une distri Linux : il faut s'assurer qu'il y est des fabricants de téléphone derrière qui suivent. Pas sûr qu'en leur promettant de s'attaquer à un potentiel de 5% de la population soit la meilleure façon de s'en assurer. Il faut donc avoir une logique identique aux autres OS et essayer de draguer le grand public pour espérer avoir des terminaux pour supporter l'OS.
BlackBerry se vautre parc qu'auprès du grand public il n'a à peu prêt rien qui le démarque de la concurrence : gamme de prix "haute", aspect matériel et logiciel "banale".
Firefox OS arrive après tout le monde, avec les mêmes "problèmes" d'aspect (pas de nouveauté sexy pour le public), des prix tirés vers le bas, mais pas suffisant pour dépasser Android. Bref, rien pour appâter le chaland. Même s'il affiche de nombreux partenaire matériel, Firefox OS n'a aucun poids lourd avec lui. Pire, le poids lourd Samsung qui aurait tout intérêt à miser sur une alternative à Google a choisi Tizen.
Franchement j'y crois moyen.
[^] # Re: http://xkcd.com/927/
Posté par TImaniac (site web personnel) . En réponse à la dépêche Firefox OS est lancé. Évalué à 6.
Euh non, BlackBerry ne domine plus rien du tout en terme de part de marché :)
[^] # Re: ça marchera jamais?
Posté par TImaniac (site web personnel) . En réponse au journal Ubuntu Edge : Révolution ou bide annoncé ?. É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: Mouai
Posté par TImaniac (site web personnel) . En réponse au journal Ubuntu Edge : Révolution ou bide annoncé ?. É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 :)