Un site Web commercial a intérêt à accepter un maximum de moyens de paiement différents pour maximiser ses ventes, mais peut conseiller un moyen de paiement plutôt qu'un autre.
Par exemple, à cause des marges de paypal, ils se font moins de sous qu'avec MasterCard et Visa, mais un client peut préférer paypal pour la sécurité. Ainsi, ils peuvent proposer paypal mais le déconseiller en disant qu'ils préfèrent qu'on les paie par carte de crédit MasterCard ou Visa directement.
Bien que préférant XFCE, je pense que KDE a le meilleur avenir.
En effet, la version 4.0 avait été une grosse régression (stabilité, fonctionnalités), mais le projet est très actif, et les améliorations fusent à vitesse grand V et ses performances sont tout à fait correctes sur un PC récent (ou un PC du futur).
XFCE: Agréable à utiliser, léger, respectant bien les spécifications freedesktop, mais pas aussi actif ou complet que KDE.
GNOME: Sacrifie les fonctions sur l'autel de l'intuitivité. Dommage, parce que GNOME2 était un très bon équilibre à mon avis.
UNITY: Pas un environnement complet. Développé par une seule petite équipe.
LXDE: C'est juste un XFCE avec quelques années de retard. Donc, un peu moins complet, un peu plus rapide et un peu moins stable.
Enlightenment: Incomplet bien qu'excellent. Avant tout un gestionnaire de fenêtres et un shell.
xterm+sh: Super bien, très standard, complet, mais pas pour les noobs.
Pour répondre à NanoTech sur la multiplication des distributions et que cela peut poser un problème
Ce n'est pas vraiment ce que j'ai dis.
Les paquetages Ubuntu étant apparemment compatibles avec Emmabuntüs, je disais justement que ce n'était pas un réel problème.
Je sais que tout administrateur voulant installer un système sur de nombreuses machines, va finalement en arriver à créer sa propre distribution, en partant d'une distrib existante, en rajoutant les pilotes manquant, les quelques programmes qu'il souhaite installer par défaut (par exemple, éducatifs), sans que cela ne pose le moindre souci.
Donc, j'applaudis à l'initiative d'installer une distro basée sur Ubuntu sur toutes les machines distribuées par Emmaüs.
Quant à ceux qui disent qu'Ubuntu n'est pas une vraie distrib Linux, j'aimerais qu'ils me disent ce qui lui manque pour en faire une vraie distrib ?
La multiplication des distro, d'une manière générale, est plutôt matière à confusion, surtout qu'elles ont souvent les mêmes objectifs (simple d'utilisation, léger, complet).
On peut d'abord se dire que c'est générateur d'incompatibilité, mais en fait il n'y en a pas autant qu'on ne croit… Beaucoup sont des "spins" (présélection de paquetages) d'autres.
Par exemple, Linux Mint, utilise essentiellement les mêmes dépôts qu'Ubuntu (en plus de quelques paquetages spécifiques sur un petit dépôt spécifique). Je suppose qu'il en est de même pour Emmabuntüs.
Ça signifie qu'un utilisateur qui installe une Linux Mint, ou une Emmabuntüs, ne fait pas un choix risqué… Il a juste une install un peu particulière d'Ubuntu.
De plus, bien qu'Ubuntu soit une distribution bien distincte de Debian, elle donne les mêmes noms au paquetages, et pour l'essentiel des paquetages communs, Ubuntu repart du source Debian, ce qui rend facile la redistribution de paquetages compatibles avec les deux systèmes, contrairement à des systèmes plus différents comme Fedora et SUSE, par exemple.
Donc, de mon point de vue, Ubuntu et dérivées, sont des distro très respectables de l'écosystème Linux, évitant de tomber dans les différences porteuses d'incompatibilité pour le plaisir.
Le profil MIDP du CLDC de J2ME est très largement supporté, et a une interface graphique (LCDUI) limitée (quoique pas si mal pour MIDP >= 2.0) mais abstraite et donc, facilement adaptée à tous types de périphériques.
On peut faire des trucs assez avancés (comme Opera Mini).
C'est essentiellement utilisé pour les petites applis des smartphones les moins cher, mais c'est aussi supporté par les plus puissants.
1) Tous les BlackBerry (sauf peut-être les derniers) supportent MIDP en natif en plus de RIM.
2) Il existe un programme convertissant une appli MIDP en appli Android.
Je crois qu'on perd beaucoup en performances vu que Dalvik != JVM.
3) Windows Mobile 6 supporte MIDP si le runtime adéquat est installé.
4) Les Nokia sous Symbian supportent MIDP (je ne suis pas sûr qu'ils supportent MIDP 2.0)
5) Sous Maemo, ce n'est pas supporté à la base, mais je crois qu'il existe un runtime proprio + un projet libre: http://maemo.org/community/brainstorm/view/delivering_java_me_to_fremantle/
6) iOS est trop fermé pour qu'Apple accepte de supporter MIDP. Mais il existe apparemment des solutions pour compiler des applications J2ME en application iPhone: http://blog.ippon.fr/2010/06/22/java-sur-iphone-utopie-ou-realite/
7) De nombreux téléphones dans des gammes de prix intermédiaire (30 à 80 euros), souvent appelés "feature phones", utilisent Nucleus RTOS ou MTK (version dérivée de Nucleus pour CPU mediatek), avec support exclusif des applications MIDP 2.0, plus ou moins nativement (je crois que certaines implémentations utilisent JBlend, et d'autres exploitent le Jazelle de l'ARM926TEJ).
8) Bada supporte MIDP en natif.
9) Windows Phone 7 ne supporte pas du tout J2ME.
Intérêts de MIDP:
1) Tourne sur prèsque toutes les plateformes mobiles.
2) Seule choix possible pour les nombreux feature phones.
Défauts:
1) Pas très "natif" sauf sur les feature phones.
2) Comme MIDP a de très nombreuses implémentations, et que certaines fonctions sont optionelles, il faut tester rigoureusement sur chaque plateforme.
3) API plus limitée, et éventuellement plus lente, que l'API native.
4) Peut nécessiter l'installation d'un runtime spécifique.
Ce qui reste le plus portable, c'est HTML+CSS+JavaScript. Notamment avec les nouvelles plateformes B2G, Tizen, WebOS. Par contre, c'est lent et pas toujours confortable à utiliser.
Avec kexec, tous les processus sont quittés. On économise juste le POST du BIOS et GRUB/LILO.
Par contre, sous Linux, on a aussi Ksplice, qui permet de patcher le noyau sans rebooter.
Ce n'est pas très compliqué pour les patches qui ne modifient pas de structure de donnée, le principe étant de placer quelques NOP avant le début de chaque fonction, pour pouvoir placer un JMP vers l'implémentation alternative, après l'avoir chargée en mémoire.
Par contre, lorsque des structures de données sont modifiées (12% des patches critiques entre 2005 et 2008), il faut du code supplémentaire gérer la conversion des structures de données.
J'achète un PC avec un système d'exploitation proprio dessus, parce que c'est nettement moins cher (je suppose qu'ils se font des marges moins grosses). Ensuite, je formate le DD et installe un système d'exploitation libre.
C'est ce que je croyais pendant longtemps, mais, apparemment, Microsoft va faire changer les choses, en apportant les avantages de la plateforme PC à la plateforme ARM.
1) BIOS pour démarrer un OS et pour les services de base d'accès aux fonctions de la plateforme (UEFI aussi bien sur x86 que sur ARM).
2) ACPI pour l'énumération et l'identification des périphériques et la distribution des ressources matérielles (DMA, IRQ).
Sachant que ces deux technologies utilisent des machines virtuelles indépendantes de l'architecture du CPU.
D'ailleurs, cela permettra de récupérer l'essentiel du noyau NT de Windows, avec simplement une réécriture du bootloader et des fonctions de bas niveau du HAL (Hardware Abstraction Layer) d'énumération, d'allocation et d'usage des DMA et IRQ.
Cela permettra à Microsoft de limiter la partie du code écrite par les OEM (qui est toujours pourrie), d'autoriser une plus grande souplesse d'assemblage des machines, et, en théorie pourrait permettre d'installer un Windows 8 générique sur ARM comme on le fait sur un PC!
En conséquence, la standardisation de cette plateforme serait aussi une aubaine pour Linux (même si Linux s'en tirait bien mieux que Windows justement parce que le code source est public) et tous les autres OS.
Mais, Microsoft ne veut pas de concurrence sur sa nouvelle plateforme! D'où la vente forcée et l'emprisonnement des machines sur leur OS.
Avec un diagnostic précis, l'utilisateur est beaucoup plus susceptible d'en tenir compte. En effet, il est bien facile d'ignorer un message "something is wrong" quand on voit que la voiture continue de fonctionner. Par contre, si on a un message "fuite d'huile" on hésite pas à la faire réparer au plus vite.
Unicode n'a pas seulement pour objectif de contenir tous les scripts des langues vivantes et mortes, mais aussi de contenir tous les caractères de tous les encodages qui ont été utilisés, ce qui permet de convertir d'un encodage X vers Unicode, puis à nouveau vers X, sans perte.
Par exemple, les notes de musique, les smileys et les flèches se trouvaient dans le jeu de caractères CP-437 utilisé dans le tampon de mémoire de l'écran des cartes VGA en mode texte, pour les caractères numérotés de 0 à 31.
Ainsi, un émulateur de terminal DOS peut vouloir supporter ces symboles, tout en utilisant de l'Unicode en interne.
Peut-être les motivations de Sony sont elles d'échapper à la contrainte légale de la GPL des autres programmes, mais le projet d'un équivalent de busybox en licence permissive me paraît intéressant.
En effet, BusyBox est pour l'instant bloqué à la GPLv2 parce que la moitié des fichiers sont en "GPLv2 only" et l'autre en GPLv2+, ce qui veut dire que l'on ne peut pas redistribuer du code mélangeant busybox avec des bouts de logiciels GPLv3 qui représente la plupart des logiciels GNU actuellement.
C'est un peu le même problème que le noyau Linux en "GPLv2 only", à la différence qu'on a globalement moins souvent envie d'intégrer du code de projets GNU dans le noyau, alors qu'on peut très bien vouloir rajouter des utilitaires GNU GPLv3 modifiés et optimisés pour la taille dans busybox...
Une autre solution serait de réécrire en GPLv2+ les fichiers "GPLv2 only" de busybox.
Par exemple, le contrôle dictatorial d'Apple sur l'AppStore permet aux utilisateurs de télécharger des applications un peu au hasard sans trop grand risque de se retrouver avec un cheval de troie. C'est aussi possible qu'Apple refuse les applications dont il juge que la "qualité" (bogues, mauvaise intégration) est trop faible.
Par contre, en effet, les applications de base pourraient être aussi intuitives et bien intégrées que dans iOS, quoique je ne sais toujours pas si iOS est vraiment plus intuitif ou si c'est juste du marketing, et je ne suis pas assez noob pour en juger par moi-même...
Imagine si ton compteur de vitesse de voiture était en m/s. Ou même en tours/min avec
l'indication du périmètre de ta roue à côté. Ca aurait un quelconque intérêt ?
Je ne pense pas.
Je suis d'accord avec le propos, mais l'analogie me semble inappropriée... En effet, on veut une vitesse absolue, indépendante du véhicule (on a choisi le km/h en France, mais on aurait pu prendre le m/s), de telle sorte que les panneaux indicateurs de limite de vitesse prennent sens.
Un compteur de vitesse proposant une échelle de 1 à 10, ou alors des mentions "très lent", "lent", "rapide, "très rapide", ne serait vraiment pas commode.
Pour les animations, c'est pas important...
Par contre, pour la sensibilité de la souris, normaliser une unité au niveau hardware et software, serait sympa, comme ça, en connaissant sa préférence on mettrait la même sur tous les systèmes, plutôt qu'y aller à tâtons à chaque fois.
Je pense aussi qu'un effet sous-estimé c'est qu'une personne qui s'est habituée, de grès ou de force, à utiliser une interface, aura toujours du mal à renoncer aux fonctions qu'il utilise. Il faut un temps d'adaptation parfois assez long avant de se retrouver aussi productif. C'est pouquoi, un changement majeur devrait toujours être motivé par des gains de productivité ou de confort à long terme.
L'argument "Une interface à la Chicago est moins intuitive que notre nouveau super-truc", omet le fait que ça n'intéresse que les gens qui n'ont jamais touché un ordinateur de leur vie, mais ça fait mal à tous les autres... Vu que l'espérance de vie est d'environ 80 ans, et qu'on utilise facilement un ordi de l'âge de 20 ans à 70 ans, si on fait un changement d'interface majeur tous les 10 ans, on fait souffrir chaque individu 5 fois environ...
Une batterie de 20 Wh (2000 mWh), ça me paraît peu crédible. 2 Wh serait plus crédible.
[mode troll]
Les gamins vont être content d'apprendre qu'ils peuvent jeter leur OLPC XO-1 pour passer au 3, parce que l'OS sera peut-être pas le même ou les nouveaux logiciels peut-être trop gourmand pour la vieille machine. Bref, exactement le contraire de l'objectif de l'OLPC qui était de fournir une plateforme stable, avec des machines remplaçables, et dont la valeur devait se situer dans les logiciels éducatifs.
Mais bon, de toute façon, comme ils n'ont rien de correct en logiciel éducatif pour l'instant, ça ne change pas grand chose.
Et puis, autant attendre l'OLPC XO-4 dans deux ans, qui coûtera 5$, avec un processeur SPARC quadri-coeur à 5 Ghz, 12 Mo de cache, deux cartes graphiques en SLI, consommant 150 mW en tout, et avec une interface vocale (pas d'écran tactile ni de clavier) fonctionnant sur le système d'exploitation B2G.
D'un autre côté l'OLPC XO-3, en omettant le clavier physique, leur apprendra qu'entrer des données dans un ordinateur (p.e. taper leurs devoirs) est une tâche fatiguante et fastidieuse, et qu'il vaut mieux utiliser l'OLPC comme une tablette doit l'être: Un produit de consommateur passif, regardant des films et s'éclatant avec des applications flashy débiles.
Le projet OLPC XO-1 était interessant, même si un peu décevant, mais l'OLPC XO-1.5/2/3 sont des bouffonneries de riches qui fantasment sur le matériel qu'on pourraît imposer aux pauvres-petits-zenfants-qui-meurent-de-faim.
[/mode troll]
Je vais être moinssé, mais j'ai dit ce que j'avais sur le coeur.
On peut offrir à l'utilisateur la possibilité d'explorer les commandes dans un arbre avec un bouton (ou une commande), un peu comme l'app-finder de XFCE, mais pour les commandes...
Pour l'installant HUD est un concept, il est sûr qu'il faudra ajouter des choses avant qu'il ne devienne fonctionnel.
D'ailleurs rien ne t'empêche de suggérer ce genre de chose à l'équipe d'Ubuntu. :)
Sur un site internet comme Google la tolérance aux fautes est incroyable mais je doute
que l'on retrouve autant de correction sur un ordinateur personnel, quelqu'un peut-il
confirmer ?
Ça tombe bien GNU/Linux est utilisé par 1 à 3% des gens... L'utilisateur moyen GNU/Linux n'est pas forcément débile et si on lui ajoute un nouveau moyen de communication avec son ordinateur, il peut en être content, du moins, du moment que l'on ne supprime pas le vieux moyen.
En effet l'interface n'est pas adaptée à tous les logiciels, mais il faut être indulgent et voir au delà des apparences.
Grace à la gestion du système unifié d'actions nommées de GTK plusieurs moyens d'accès peuvent être facilement offerts (p.e. menu + HUD) à l'utilisateur pour les mêmes commandes. Pour l'instant HUD semble "remplacer" les menus, mais ça ne sera pas forcément le cas de la version finale.
Pour moi la démarche qui amène à Ubuntu HUD (mais je mets Gnome 3 dans le même paquet)
est avant tout guidée par l'esthétisme mais absolument pas par l'ergonomie ni
l'utilisabilité de la chose.
Là, je ne suis pas d'accord. Ça me paraît une interface Geek-friendly expérimentale. En grand amateur de Vim, je pense que ça peut être ergonomique pour les éditeurs de texte et éditeurs hexadécimaux...
Par contre, si c'est disponible dès la 12.04, ça risque de ne pas être suffisamment testé et fignolé.. Les utilisateurs Ubuntu deviennent de plus en plus des béta-testeurs... Politique discutable.
Je ne vois pas comment le FreeRunner peut avoir un hardware 100% ouvert en étant basé sur un coeur ARM920T, qui est non seulement breveté, mais en plus dont les circuits sont copyrightés par ARM Holdings, et uniquement disponibles sous accord de non divulgation, si je ne m'abuse.
Et puis quand on voit sur les schémas du montage sur le PCB:
"SHEET18-20 deleted for NDA"
On se dit que la définition de 100% est toute relative.
Je me suis déjà fait avoir avec le Ben NanoNote soi-disant 100% ouvert, mais dont les instructions SIMD (Single Instruction Multiple Data) ne sont même pas documentées!
Après, le logiciel est peut-être 100% ouvert (le plus important à mon avis), mais ça ne semble pas être le cas du hardware.
Il y a un aspect très négatif dans fauxpensource qui n'existe pas dans clopen ni
dans open-opaque, et qui ne représente pas la réalité de Android. Lorsque les sources
d'Android sont livrées, c'est carré et ça fonctionne. Il n'y a pas de partie
"fauxpensource" qui reste dans un coin. Il y a un mode de dev en interne
exclusivement, et des sources publiées ensuite.
L'Android vanilla, c'est de l'ouvert pur et dur. Ce sont les Android modifiés par les OEM qui ne sont pas si ouvert que ça... Code source indisponible, parfois impossibilité de rooter l'appareil ou alors code source tellement infâme qu'ils est quasiment inutilisable et nécessite des années de travail de réécriture pour être intégré correctement au noyau (p.e. WM-8505).
Windows CE/Phone 7 souffre des mêmes problèmes qu'Android... Le noyau est modifié par les OEM, et on dépend d'eux pour les mises à jour.
Apple c'est différent, comme il contrôle les deux (OS et appareil), il peut garantir à l'utilisateur qu'il pourra upgrader son appareil, ou au contraire, volontairement les empêcher d'upgrader s'il juge que c'est bon pour son marché.
Avec la différence qu'une fois qu'on connaît une distribution Linux, on peut installer la même sur tous ses PC. Par exemple, j'ai installé une CentOS sur un netbook qui était livré par défaut avec OpenSUSE... Pas de souci, je ne dépend pas des choix des vendeurs.
Finalement Android c'est pas assez ouvert (développement non collaboratif) mais en
fait ça l'est trop (les constructeurs font ce qu'ils veulent du code)… Va falloir se
décider.
Je n'ai pas dit qu'Android n'est pas ouvert. Bien au contraire, mais on voit dans la vraie vie, que l'ouverture du code ne suffit pas à garantir la perennité de l'utilisateur. Sont en cause le manque de standardisation de la plateforme (chipsets ARM et MIPS) et d'un modèle de pilote moins dépendant de la version du noyau, les vendeurs intégrant atrocement leurs pilotes de telle sorte qu'il est très difficile de les porter à un noyau Android plus récent. En plus, bien souvent les constructeurs n'en donnent même pas le source, échappant illégallement à leurs devoirs de respect de la GPL.
Actuellement d'ailleurs il y a un travail de fond sur le support Linux de la plateforme ARM, avec mise en place progressive d'une couche d'abstraction de bus d'accès au matériel ARM, afin de réduire le code ultra-spécifique à un chipset donné, et de porter beaucoup plus facilement le noyau à de nouveaux chipsets.
L'autre possibilité, ce serait que la version de référence d'Android supporte un peu tous les chipsets ARM en circulation, plutôt que de laisser le boulot de port aux constructeurs. Un peu comme les distributions Linux qui contiennent tous les pilotes pour tout le matos PC.
D'ailleurs si on a la chance d'avoir un chipset supporté par le mainline kernel ou le noyau Android, alors, on doit pouvoir assez facilement upgrader sa machine à une version récente d'Android.
Une de mes machines ARM ayant un WM-8505, je suis heureux de voir qu'est en cours le port des pilotes, sous forme propre et fonctionnelle, pour le noyau Linux.
Le gros problème qui est fait par la plupart des journalistes est d'assimiler
Android à Google, alors que l'OS préinstallé dans leur téléphone n'a de Google que la base.
Difficile de prévenir des déviances sur les APIs, des bugs bizarres etc.
Ce qui signifie que quand on achète une machine portant le label "Android", on ne sait pas vraiment ce qu'on va avoir, un peu comme quand on achète une machine avec firmware fait maison du constructeur (mais tout de même dans une mesure moindre).
Et bien sûr, ne compte pas sur le constructeur pour te dire ce qu'ils ont modifié, ni les bogues qu'ils ont rajouté. On doit le découvrir par soi même.
[^] # Re: De mon point de vue non
Posté par NanoTech . En réponse au journal Paypal et la liberté d'expression. Évalué à 1.
Un site Web commercial a intérêt à accepter un maximum de moyens de paiement différents pour maximiser ses ventes, mais peut conseiller un moyen de paiement plutôt qu'un autre.
Par exemple, à cause des marges de paypal, ils se font moins de sous qu'avec MasterCard et Visa, mais un client peut préférer paypal pour la sécurité. Ainsi, ils peuvent proposer paypal mais le déconseiller en disant qu'ils préfèrent qu'on les paie par carte de crédit MasterCard ou Visa directement.
# KDE, bien que je ne l'utilise pas
Posté par NanoTech . En réponse au sondage Sur quel environnement de bureau misez-vous dans le futur ?. Évalué à 2. Dernière modification le 14 mai 2012 à 13:30.
Bien que préférant XFCE, je pense que KDE a le meilleur avenir.
En effet, la version 4.0 avait été une grosse régression (stabilité, fonctionnalités), mais le projet est très actif, et les améliorations fusent à vitesse grand V et ses performances sont tout à fait correctes sur un PC récent (ou un PC du futur).
XFCE: Agréable à utiliser, léger, respectant bien les spécifications freedesktop, mais pas aussi actif ou complet que KDE.
GNOME: Sacrifie les fonctions sur l'autel de l'intuitivité. Dommage, parce que GNOME2 était un très bon équilibre à mon avis.
UNITY: Pas un environnement complet. Développé par une seule petite équipe.
LXDE: C'est juste un XFCE avec quelques années de retard. Donc, un peu moins complet, un peu plus rapide et un peu moins stable.
Enlightenment: Incomplet bien qu'excellent. Avant tout un gestionnaire de fenêtres et un shell.
xterm+sh: Super bien, très standard, complet, mais pas pour les noobs.
[^] # Re: Qu'apporte réellement votre distribution ?
Posté par NanoTech . En réponse à la dépêche Emmabuntüs 2 (12.04) en version Preview sur freetorrent.fr. Évalué à 1. Dernière modification le 07 mai 2012 à 11:43.
Ce n'est pas vraiment ce que j'ai dis.
Les paquetages Ubuntu étant apparemment compatibles avec Emmabuntüs, je disais justement que ce n'était pas un réel problème.
Je sais que tout administrateur voulant installer un système sur de nombreuses machines, va finalement en arriver à créer sa propre distribution, en partant d'une distrib existante, en rajoutant les pilotes manquant, les quelques programmes qu'il souhaite installer par défaut (par exemple, éducatifs), sans que cela ne pose le moindre souci.
Donc, j'applaudis à l'initiative d'installer une distro basée sur Ubuntu sur toutes les machines distribuées par Emmaüs.
Quant à ceux qui disent qu'Ubuntu n'est pas une vraie distrib Linux, j'aimerais qu'ils me disent ce qui lui manque pour en faire une vraie distrib ?
[^] # Re: fashion
Posté par NanoTech . En réponse à la dépêche Emmabuntüs 2 (12.04) en version Preview sur freetorrent.fr. Évalué à 3.
La multiplication des distro, d'une manière générale, est plutôt matière à confusion, surtout qu'elles ont souvent les mêmes objectifs (simple d'utilisation, léger, complet).
On peut d'abord se dire que c'est générateur d'incompatibilité, mais en fait il n'y en a pas autant qu'on ne croit… Beaucoup sont des "spins" (présélection de paquetages) d'autres.
Par exemple, Linux Mint, utilise essentiellement les mêmes dépôts qu'Ubuntu (en plus de quelques paquetages spécifiques sur un petit dépôt spécifique). Je suppose qu'il en est de même pour Emmabuntüs.
Ça signifie qu'un utilisateur qui installe une Linux Mint, ou une Emmabuntüs, ne fait pas un choix risqué… Il a juste une install un peu particulière d'Ubuntu.
De plus, bien qu'Ubuntu soit une distribution bien distincte de Debian, elle donne les mêmes noms au paquetages, et pour l'essentiel des paquetages communs, Ubuntu repart du source Debian, ce qui rend facile la redistribution de paquetages compatibles avec les deux systèmes, contrairement à des systèmes plus différents comme Fedora et SUSE, par exemple.
Donc, de mon point de vue, Ubuntu et dérivées, sont des distro très respectables de l'écosystème Linux, évitant de tomber dans les différences porteuses d'incompatibilité pour le plaisir.
# J2ME
Posté par NanoTech . En réponse au journal Le développement en natif pour un soft universel ?. Évalué à 1. Dernière modification le 12 avril 2012 à 22:50.
Le profil MIDP du CLDC de J2ME est très largement supporté, et a une interface graphique (LCDUI) limitée (quoique pas si mal pour MIDP >= 2.0) mais abstraite et donc, facilement adaptée à tous types de périphériques.
On peut faire des trucs assez avancés (comme Opera Mini).
C'est essentiellement utilisé pour les petites applis des smartphones les moins cher, mais c'est aussi supporté par les plus puissants.
1) Tous les BlackBerry (sauf peut-être les derniers) supportent MIDP en natif en plus de RIM.
2) Il existe un programme convertissant une appli MIDP en appli Android.
Je crois qu'on perd beaucoup en performances vu que Dalvik != JVM.
3) Windows Mobile 6 supporte MIDP si le runtime adéquat est installé.
4) Les Nokia sous Symbian supportent MIDP (je ne suis pas sûr qu'ils supportent MIDP 2.0)
5) Sous Maemo, ce n'est pas supporté à la base, mais je crois qu'il existe un runtime proprio + un projet libre:
http://maemo.org/community/brainstorm/view/delivering_java_me_to_fremantle/
6) iOS est trop fermé pour qu'Apple accepte de supporter MIDP. Mais il existe apparemment des solutions pour compiler des applications J2ME en application iPhone:
http://blog.ippon.fr/2010/06/22/java-sur-iphone-utopie-ou-realite/
7) De nombreux téléphones dans des gammes de prix intermédiaire (30 à 80 euros), souvent appelés "feature phones", utilisent Nucleus RTOS ou MTK (version dérivée de Nucleus pour CPU mediatek), avec support exclusif des applications MIDP 2.0, plus ou moins nativement (je crois que certaines implémentations utilisent JBlend, et d'autres exploitent le Jazelle de l'ARM926TEJ).
8) Bada supporte MIDP en natif.
9) Windows Phone 7 ne supporte pas du tout J2ME.
Intérêts de MIDP:
1) Tourne sur prèsque toutes les plateformes mobiles.
2) Seule choix possible pour les nombreux feature phones.
Défauts:
1) Pas très "natif" sauf sur les feature phones.
2) Comme MIDP a de très nombreuses implémentations, et que certaines fonctions sont optionelles, il faut tester rigoureusement sur chaque plateforme.
3) API plus limitée, et éventuellement plus lente, que l'API native.
4) Peut nécessiter l'installation d'un runtime spécifique.
Ce qui reste le plus portable, c'est HTML+CSS+JavaScript. Notamment avec les nouvelles plateformes B2G, Tizen, WebOS. Par contre, c'est lent et pas toujours confortable à utiliser.
# C'est pas la taille qui compte
Posté par NanoTech . En réponse au sondage Quel est le meilleur indicateur pour mesurer la taille de sa geekitude ?. Évalué à 0.
sed '1,2d' /proc/partitions|wc -l
Est un bien meilleur indicateur… Ça reflète un peu le nombre d'OS installés.
[^] # Re: Innovant
Posté par NanoTech . En réponse à la dépêche Rétrospective sur le noyau 2.6.32. Évalué à 7.
Avec kexec, tous les processus sont quittés. On économise juste le POST du BIOS et GRUB/LILO.
Par contre, sous Linux, on a aussi Ksplice, qui permet de patcher le noyau sans rebooter.
Ce n'est pas très compliqué pour les patches qui ne modifient pas de structure de donnée, le principe étant de placer quelques NOP avant le début de chaque fonction, pour pouvoir placer un JMP vers l'implémentation alternative, après l'avoir chargée en mémoire.
Par contre, lorsque des structures de données sont modifiées (12% des patches critiques entre 2005 et 2008), il faut du code supplémentaire gérer la conversion des structures de données.
# Je supprime les logiciels proprio
Posté par NanoTech . En réponse au sondage j'achète un ordinateur pour 2012, comment vais-je me faire rembourser le prix des logiciels non désirés?. Évalué à 5.
J'achète un PC avec un système d'exploitation proprio dessus, parce que c'est nettement moins cher (je suppose qu'ils se font des marges moins grosses). Ensuite, je formate le DD et installe un système d'exploitation libre.
[^] # Re: Windows 8 sur ARM : pas étonnant
Posté par NanoTech . En réponse à la dépêche Vente liée: un pas en avant, un pas en arrière.... Évalué à 1.
C'est ce que je croyais pendant longtemps, mais, apparemment, Microsoft va faire changer les choses, en apportant les avantages de la plateforme PC à la plateforme ARM.
1) BIOS pour démarrer un OS et pour les services de base d'accès aux fonctions de la plateforme (UEFI aussi bien sur x86 que sur ARM).
2) ACPI pour l'énumération et l'identification des périphériques et la distribution des ressources matérielles (DMA, IRQ).
Sachant que ces deux technologies utilisent des machines virtuelles indépendantes de l'architecture du CPU.
D'ailleurs, cela permettra de récupérer l'essentiel du noyau NT de Windows, avec simplement une réécriture du bootloader et des fonctions de bas niveau du HAL (Hardware Abstraction Layer) d'énumération, d'allocation et d'usage des DMA et IRQ.
Cela permettra à Microsoft de limiter la partie du code écrite par les OEM (qui est toujours pourrie), d'autoriser une plus grande souplesse d'assemblage des machines, et, en théorie pourrait permettre d'installer un Windows 8 générique sur ARM comme on le fait sur un PC!
En conséquence, la standardisation de cette plateforme serait aussi une aubaine pour Linux (même si Linux s'en tirait bien mieux que Windows justement parce que le code source est public) et tous les autres OS.
Mais, Microsoft ne veut pas de concurrence sur sa nouvelle plateforme! D'où la vente forcée et l'emprisonnement des machines sur leur OS.
# Autre bénéfice
Posté par NanoTech . En réponse à la dépêche Le voyant de dysfonctionnement n'éclaire en rien. Évalué à 10. Dernière modification le 11 février 2012 à 09:47.
Avec un diagnostic précis, l'utilisateur est beaucoup plus susceptible d'en tenir compte. En effet, il est bien facile d'ignorer un message "something is wrong" quand on voit que la voiture continue de fonctionner. Par contre, si on a un message "fuite d'huile" on hésite pas à la faire réparer au plus vite.
[^] # Re: Caractères absurdes
Posté par NanoTech . En réponse à la dépêche Nouvelle version d'Unicode : la 6.1.0. Évalué à 10.
Unicode n'a pas seulement pour objectif de contenir tous les scripts des langues vivantes et mortes, mais aussi de contenir tous les caractères de tous les encodages qui ont été utilisés, ce qui permet de convertir d'un encodage X vers Unicode, puis à nouveau vers X, sans perte.
Par exemple, les notes de musique, les smileys et les flèches se trouvaient dans le jeu de caractères CP-437 utilisé dans le tampon de mémoire de l'écran des cartes VGA en mode texte, pour les caractères numérotés de 0 à 31.
Ainsi, un émulateur de terminal DOS peut vouloir supporter ces symboles, tout en utilisant de l'Unicode en interne.
Par contre, je ne sais pas d'où vient le "caca".
# Bénéfices secondaires
Posté par NanoTech . En réponse à la dépêche Sony : Ma propriété intellectuelle vaut plus que la vôtre. Évalué à 0.
Peut-être les motivations de Sony sont elles d'échapper à la contrainte légale de la GPL des autres programmes, mais le projet d'un équivalent de busybox en licence permissive me paraît intéressant.
En effet, BusyBox est pour l'instant bloqué à la GPLv2 parce que la moitié des fichiers sont en "GPLv2 only" et l'autre en GPLv2+, ce qui veut dire que l'on ne peut pas redistribuer du code mélangeant busybox avec des bouts de logiciels GPLv3 qui représente la plupart des logiciels GNU actuellement.
C'est un peu le même problème que le noyau Linux en "GPLv2 only", à la différence qu'on a globalement moins souvent envie d'intégrer du code de projets GNU dans le noyau, alors qu'on peut très bien vouloir rajouter des utilitaires GNU GPLv3 modifiés et optimisés pour la taille dans busybox...
Une autre solution serait de réécrire en GPLv2+ les fichiers "GPLv2 only" de busybox.
[^] # Re: Wozniak n'est pas Jobs
Posté par NanoTech . En réponse à la dépêche Android et son monde. Évalué à 1.
Par exemple, le contrôle dictatorial d'Apple sur l'AppStore permet aux utilisateurs de télécharger des applications un peu au hasard sans trop grand risque de se retrouver avec un cheval de troie. C'est aussi possible qu'Apple refuse les applications dont il juge que la "qualité" (bogues, mauvaise intégration) est trop faible.
Par contre, en effet, les applications de base pourraient être aussi intuitives et bien intégrées que dans iOS, quoique je ne sais toujours pas si iOS est vraiment plus intuitif ou si c'est juste du marketing, et je ne suis pas assez noob pour en juger par moi-même...
[^] # Re: Rha mais oui mais non !
Posté par NanoTech . En réponse à la dépêche Cinnamon 1.2, le fork de Gnome-shell. Évalué à 4.
Je suis d'accord avec le propos, mais l'analogie me semble inappropriée... En effet, on veut une vitesse absolue, indépendante du véhicule (on a choisi le km/h en France, mais on aurait pu prendre le m/s), de telle sorte que les panneaux indicateurs de limite de vitesse prennent sens.
Un compteur de vitesse proposant une échelle de 1 à 10, ou alors des mentions "très lent", "lent", "rapide, "très rapide", ne serait vraiment pas commode.
Pour les animations, c'est pas important...
Par contre, pour la sensibilité de la souris, normaliser une unité au niveau hardware et software, serait sympa, comme ça, en connaissant sa préférence on mettrait la même sur tous les systèmes, plutôt qu'y aller à tâtons à chaque fois.
[^] # Re: Est-ce vraiment un fork ?
Posté par NanoTech . En réponse à la dépêche Cinnamon 1.2, le fork de Gnome-shell. Évalué à 1.
Étant donné que Linux Mint offre aussi l'interface MATE, ça veut dire qu'on aura 3 choix de "GNOME".
1) MATE
2) gnome-shell vanilla
3) Cinnamon
Du coup, ça devient la distro qui laisse le plus de liberté de choix d'environements à l'utilisateur.
Vive Linux Mint!
[^] # Re: Rha mais oui mais non !
Posté par NanoTech . En réponse à la dépêche Cinnamon 1.2, le fork de Gnome-shell. Évalué à 3. Dernière modification le 27 janvier 2012 à 13:37.
Je pense aussi qu'un effet sous-estimé c'est qu'une personne qui s'est habituée, de grès ou de force, à utiliser une interface, aura toujours du mal à renoncer aux fonctions qu'il utilise. Il faut un temps d'adaptation parfois assez long avant de se retrouver aussi productif. C'est pouquoi, un changement majeur devrait toujours être motivé par des gains de productivité ou de confort à long terme.
L'argument "Une interface à la Chicago est moins intuitive que notre nouveau super-truc", omet le fait que ça n'intéresse que les gens qui n'ont jamais touché un ordinateur de leur vie, mais ça fait mal à tous les autres... Vu que l'espérance de vie est d'environ 80 ans, et qu'on utilise facilement un ordi de l'âge de 20 ans à 70 ans, si on fait un changement d'interface majeur tous les 10 ans, on fait souffrir chaque individu 5 fois environ...
[^] # Re: OS
Posté par NanoTech . En réponse à la dépêche OLPC XO 3 en approche. Évalué à 10.
Une batterie de 20 Wh (2000 mWh), ça me paraît peu crédible. 2 Wh serait plus crédible.
[mode troll]
Les gamins vont être content d'apprendre qu'ils peuvent jeter leur OLPC XO-1 pour passer au 3, parce que l'OS sera peut-être pas le même ou les nouveaux logiciels peut-être trop gourmand pour la vieille machine. Bref, exactement le contraire de l'objectif de l'OLPC qui était de fournir une plateforme stable, avec des machines remplaçables, et dont la valeur devait se situer dans les logiciels éducatifs.
Mais bon, de toute façon, comme ils n'ont rien de correct en logiciel éducatif pour l'instant, ça ne change pas grand chose.
Et puis, autant attendre l'OLPC XO-4 dans deux ans, qui coûtera 5$, avec un processeur SPARC quadri-coeur à 5 Ghz, 12 Mo de cache, deux cartes graphiques en SLI, consommant 150 mW en tout, et avec une interface vocale (pas d'écran tactile ni de clavier) fonctionnant sur le système d'exploitation B2G.
D'un autre côté l'OLPC XO-3, en omettant le clavier physique, leur apprendra qu'entrer des données dans un ordinateur (p.e. taper leurs devoirs) est une tâche fatiguante et fastidieuse, et qu'il vaut mieux utiliser l'OLPC comme une tablette doit l'être: Un produit de consommateur passif, regardant des films et s'éclatant avec des applications flashy débiles.
Le projet OLPC XO-1 était interessant, même si un peu décevant, mais l'OLPC XO-1.5/2/3 sont des bouffonneries de riches qui fantasment sur le matériel qu'on pourraît imposer aux pauvres-petits-zenfants-qui-meurent-de-faim.
[/mode troll]
Je vais être moinssé, mais j'ai dit ce que j'avais sur le coeur.
[^] # Re: Fausse bonne idée!
Posté par NanoTech . En réponse à la dépêche HUD pour « Head-Up Display » : disparition des menus dans Unity. Évalué à 1.
On peut offrir à l'utilisateur la possibilité d'explorer les commandes dans un arbre avec un bouton (ou une commande), un peu comme l'app-finder de XFCE, mais pour les commandes...
Pour l'installant HUD est un concept, il est sûr qu'il faudra ajouter des choses avant qu'il ne devienne fonctionnel.
D'ailleurs rien ne t'empêche de suggérer ce genre de chose à l'équipe d'Ubuntu. :)
[^] # Re: Simplification à l'extrême ?
Posté par NanoTech . En réponse à la dépêche HUD pour « Head-Up Display » : disparition des menus dans Unity. Évalué à 6.
Ce n'est surtout pas trop souhaitable.
Je veux taper:
deflate all
Je tape:
delate all
Ça m'autocorrige en:
delete all
Chouette!
[^] # Re: Nom
Posté par NanoTech . En réponse à la dépêche HUD pour « Head-Up Display » : disparition des menus dans Unity. Évalué à 1.
Ça tombe bien GNU/Linux est utilisé par 1 à 3% des gens... L'utilisateur moyen GNU/Linux n'est pas forcément débile et si on lui ajoute un nouveau moyen de communication avec son ordinateur, il peut en être content, du moins, du moment que l'on ne supprime pas le vieux moyen.
[^] # Re: Vim !
Posté par NanoTech . En réponse à la dépêche HUD pour « Head-Up Display » : disparition des menus dans Unity. Évalué à 0. Dernière modification le 25 janvier 2012 à 19:14.
En effet l'interface n'est pas adaptée à tous les logiciels, mais il faut être indulgent et voir au delà des apparences.
Grace à la gestion du système unifié d'actions nommées de GTK plusieurs moyens d'accès peuvent être facilement offerts (p.e. menu + HUD) à l'utilisateur pour les mêmes commandes. Pour l'instant HUD semble "remplacer" les menus, mais ça ne sera pas forcément le cas de la version finale.
Là, je ne suis pas d'accord. Ça me paraît une interface Geek-friendly expérimentale. En grand amateur de Vim, je pense que ça peut être ergonomique pour les éditeurs de texte et éditeurs hexadécimaux...
Par contre, si c'est disponible dès la 12.04, ça risque de ne pas être suffisamment testé et fignolé.. Les utilisateurs Ubuntu deviennent de plus en plus des béta-testeurs... Politique discutable.
# 100% ouvert?
Posté par NanoTech . En réponse à la dépêche Ubuntu sur les terminaux mobiles et les tablettes. Évalué à 4.
Je ne vois pas comment le FreeRunner peut avoir un hardware 100% ouvert en étant basé sur un coeur ARM920T, qui est non seulement breveté, mais en plus dont les circuits sont copyrightés par ARM Holdings, et uniquement disponibles sous accord de non divulgation, si je ne m'abuse.
Et puis quand on voit sur les schémas du montage sur le PCB:
"SHEET18-20 deleted for NDA"
On se dit que la définition de 100% est toute relative.
Je me suis déjà fait avoir avec le Ben NanoNote soi-disant 100% ouvert, mais dont les instructions SIMD (Single Instruction Multiple Data) ne sont même pas documentées!
Après, le logiciel est peut-être 100% ouvert (le plus important à mon avis), mais ça ne semble pas être le cas du hardware.
[^] # Re: Clopen
Posté par NanoTech . En réponse à la dépêche Les actus du Grand Architecte d'Android. Évalué à 0.
L'Android vanilla, c'est de l'ouvert pur et dur. Ce sont les Android modifiés par les OEM qui ne sont pas si ouvert que ça... Code source indisponible, parfois impossibilité de rooter l'appareil ou alors code source tellement infâme qu'ils est quasiment inutilisable et nécessite des années de travail de réécriture pour être intégré correctement au noyau (p.e. WM-8505).
Windows CE/Phone 7 souffre des mêmes problèmes qu'Android... Le noyau est modifié par les OEM, et on dépend d'eux pour les mises à jour.
Apple c'est différent, comme il contrôle les deux (OS et appareil), il peut garantir à l'utilisateur qu'il pourra upgrader son appareil, ou au contraire, volontairement les empêcher d'upgrader s'il juge que c'est bon pour son marché.
[^] # Re: Fragmentation
Posté par NanoTech . En réponse à la dépêche Les actus du Grand Architecte d'Android. Évalué à 0.
Avec la différence qu'une fois qu'on connaît une distribution Linux, on peut installer la même sur tous ses PC. Par exemple, j'ai installé une CentOS sur un netbook qui était livré par défaut avec OpenSUSE... Pas de souci, je ne dépend pas des choix des vendeurs.
Je n'ai pas dit qu'Android n'est pas ouvert. Bien au contraire, mais on voit dans la vraie vie, que l'ouverture du code ne suffit pas à garantir la perennité de l'utilisateur. Sont en cause le manque de standardisation de la plateforme (chipsets ARM et MIPS) et d'un modèle de pilote moins dépendant de la version du noyau, les vendeurs intégrant atrocement leurs pilotes de telle sorte qu'il est très difficile de les porter à un noyau Android plus récent. En plus, bien souvent les constructeurs n'en donnent même pas le source, échappant illégallement à leurs devoirs de respect de la GPL.
Actuellement d'ailleurs il y a un travail de fond sur le support Linux de la plateforme ARM, avec mise en place progressive d'une couche d'abstraction de bus d'accès au matériel ARM, afin de réduire le code ultra-spécifique à un chipset donné, et de porter beaucoup plus facilement le noyau à de nouveaux chipsets.
L'autre possibilité, ce serait que la version de référence d'Android supporte un peu tous les chipsets ARM en circulation, plutôt que de laisser le boulot de port aux constructeurs. Un peu comme les distributions Linux qui contiennent tous les pilotes pour tout le matos PC.
D'ailleurs si on a la chance d'avoir un chipset supporté par le mainline kernel ou le noyau Android, alors, on doit pouvoir assez facilement upgrader sa machine à une version récente d'Android.
Une de mes machines ARM ayant un WM-8505, je suis heureux de voir qu'est en cours le port des pilotes, sous forme propre et fonctionnelle, pour le noyau Linux.
[^] # Re: Fragmentation
Posté par NanoTech . En réponse à la dépêche Les actus du Grand Architecte d'Android. Évalué à 2.
Ce qui signifie que quand on achète une machine portant le label "Android", on ne sait pas vraiment ce qu'on va avoir, un peu comme quand on achète une machine avec firmware fait maison du constructeur (mais tout de même dans une mesure moindre).
Et bien sûr, ne compte pas sur le constructeur pour te dire ce qu'ils ont modifié, ni les bogues qu'ils ont rajouté. On doit le découvrir par soi même.