Ph Husson a écrit 2699 commentaires

M'étonnerait que Dell arrive à faire une distrib GNU/Linux sans produit GPLv3 (même si j'ai aucune stat sur l'abondance de la gplv3). Bon après ils peuvent encore utiliser Chrome OS.

De la même manière que les 35heures (v)ont créer(é) plein d'emplois, effectivement.

Dans d'autres pays, la grève est synonyme d'échec de la part des syndicat,
Beau lancé de troll, mais un peu trop éparpillé, et sur plusieurs messages, ça va avoir du mal à démarrer. J'mets 7/10.

C'est l'idée.

Bah la différence c'est que vlc fait ça avec des APIs apropriés, qui sont relativement performantes.
Apparement, en flash c'est fait "à la main" (en tout cas c'est ce que j'interprete du fait qu'en fenêtré ça marche, et en plein écran ça rame.), donc bon c'est dur.

Un tableau aussi détaillé ça m'étonnerait, mais j'vais tacher de faire ça à la louche par comparaison avec le N900, et je me base sur la plateforme Snapdragon (les msm7k ont plus de trucs fermés)
Comme le N900:
-OpenGL ES fermée (du moins l'implém hard, l'implém soft est libre mais bon...)
-Le boot loader est fermé (il fait aussi flasher, et l'appli côté ordi est libre). À noter que Qualcomm a annoncé (et sorti.) un bootloader alternatif libre.
-Tout ce qui est gestion GSM est fermé
-Ce qui tient de la PIM est fermé (à comparer à funambol, le calendrier, libaccounts etc): Il s'agit de google talk/mail/calendar principalement, qui n'ont pas vraiment d'alternatives libres. (google mail a k9mail et google talk extrempp mais bon.. ça reste maigre)
-Ce qui est géolocalisation par GSM est fermé
-Le "wizard" du début est bien fermé (il ne sert qu'à rentrer son compte google, sans apps google forcement ça va pas loin ...)

Contrairement au N900:
-Un point que je ne vois pas sur ce schéma c'est le market, sous android il est bien proprio, mais il y a plein de markets alternatifs tout à fait utilisable.
-La partie localisation dans maemo fait aussi réference au GPS je pense, celui ci est ouvert/ouvrable sous android
-Tout ce qui est multimedia est ouvert/ouvrable. (Il existe des implémentations alternatives fermées quand même pour gérer plus de formats, genre sur l'acer liquid qui rajoute le support de formats tels que le divx ou le WMV (à l'heure actuelle, l'android libre ne gere que le mp4/H264 et H264))

Par contre, ils parlent de tout ce qui est graphismes et sons, je n'ai strictement aucune idée de la licence utilisée pour ceux là dans android. A priori c'est au moins redistribuable librement

Voilà, c'est à peu pres tout ce qui me passe par l'esprit en regardant ce graph.

PS: À noter que partout où je dis android ici, c'est Android/Snapdragon, Android/msm7k est bien plus fermé, et je ne connais pas du tout Android/Omap ni Android/Samsung (ou autre.)

Ça veut dire que l'opérateur (ou pas... cf les annonces récentes sur la sécurité GSM) peut demander la position GPS d'un téléphone.
Rien de neuf là dedans, c'est même devenu une obligation légale pour qu'un téléphone rentre sur le marché américain à ma connaissance.

Pour le défaut niveau driver et ta remarque sur HTC, je ne peux que raler:
-La quasi-totalité des drivers sont libres.
À ma connaissance, sur les systèmes récents (snapdragon), seule la 3D et la communication radio (au sens propre, pas au sens processeur radio) est fermée, et encore c'est des simples commandes AT relativement banales, je crois bien que le projet Replicant a une RIL (cette interface de communication.) qui marche. Concernant cette dernière, je pense même qu'ils peuvent avoir des problèmes de secret "défense" derrière: J'ai découvert à ma grande surprise que la possibilité de faire de requêtes GPS à distance est gérée par cette RIL.
Et concernant la 3D, la partie noyau du driver a été libérée y a quelques mois, je ne sais pas trop s'ils prévoient quoique ce soit concernant la partie utilisateur. (qui est amha d'un intérêt extrêmement limité)
-Et même mieux que la liberté (parce qu'avec android y a des fois des sueurs froides de ce point de vue):
À l'heure actuelle, la quasi totalité des drivers permettent d'utiliser des APIs linux propres !
Drivers ALSA pour le son, V4L2 pour les caméra, framebuffer pour la vidéo, driver Xorg accéléré, avec gestion 3D (proprio quand même la partie 3D). Il n'y a guère que l'accélération de décodage vidéo qui n'utilise pas d'API propre, étant donné qu'il n'y en a pas. Mais là ils se basent quand même sur un produit déjà existant, OpenCore, et qui peut tout à fait être utilisé sur un GNU/Linux normal.

Mais tout ce travail ne vient PAS de Google ni de HTC.
Il vient de Qualcomm. C'est une société qui vend du hard, et point barre. Elle fournit des drivers pour ce qu'on lui demande, et le fait (amha) bien, même s'ils pourraient essayer de pousser un peu plus fort en mainline.

Maintenant que j'ai dit du bien des noyaux qualcomm, je vais pouvoir taper sur Google/HTC.
J'ai dit précedement que qualcomm fournit des APIs Linux standard, sauf qu'en fait, Android HTC ne les utilise pas du tout.
Par exemple, la gestion sonore ou de la camera se fait à travers des périphériques /dev/msm_*, la gestion de la mémoire "physique" (nécessaire car la mémoire est partagée entre tous les "coeurs" du SoC, 3D, DSP, etc) se fait par un périphérique créé pour l'occasion (pmem). Qualcomm tend à se débarrasser de cette dépendance, Google eux ne font rien pour.
Mais tout ça tient un peu de l'historique, car je suppose que ce sont des contournements par flemme qu'avaient fait Qualcomm au début de ses noyaux. Maintenant on va parler de l'actuel, après différentes évolutions
Donc la gestion sonore sur les plate-formes qualcomm reste globalement complétement dans le noyau, la seule chose qui change par rapport à de l'ALSA est l'API complétement différente. Pour le son, un truc qui peut toujours servir est un amplificateur, pour sortir sur un haut parleur (rien de bien méchant, 3/4 commandes sur I2C et c'est réglé). Et bien ce que Google et HTC ont fait (aussi bien sur le Desire que le Nexus One), est de faire un driver I2C idiot, qui ne fait que transmettre les commandes entre l'espace utilisateur et le noyau. Ainsi donc, c'est à l'espace utilisateur de s'adapter au hard. (Autant utiliser un micro noyau non ?). Mais les commandes I2C sont quand même sous formes d'ioctl explicite genre SET_AGC_VALUE ou ce genre de choses. Mais toujours chez HTC(y compris N1), on trouve un petit device dans /dev, au doux nom de htc_acoustic. Ce périphérique est juste là pour mettre à l'espace utilisateur d'accéder à la mémoire physique de la gestion sonore (en fait il s'agit de calibrer les CAN/CNA de ce que j'ai pu voir). Ainsi donc on a un noyau complètement libre, pourtant on reste avec du son complètement inutilisable chez HTC, alors qu'avec d'autres fournisseurs ça juste marche. Bon après, écrire un driver pour remplacer cette saleté de htc_acoustic n'est pas spécialement compliqué non plus à faire.
Enfin, histoire de râler encore un peu plus, Qualcomm propose des driver GPS libres. Google/HTC préfèrent utiliser une version précedente (encore un héritage en fait) propriétaire.

Vivement qu'il soit implémenté dans les navigateurs! (l'iPhone est en très grosse avance la dessus, il l'implémente déjà, et oui, un matériel fermé en avance sur un protocole libre... Le libre a perdu bêtement des points à ne pas anticiper ce genre d'implémentations)
Mon téléphone qui date d'avant l'iPhone le gère.
Mon player vidéo favoris (mplayer le gère).
Non en vrai, à peu pres tout ce qui est multimédia le gère. C'est à se demander si le HTML5 est prévu pour être multimédia en fait.

Plus sérieusement, des solutions libres arrivent à lire le code Flash d'un site comme youtube il me semble.
Ils doivent avoir un décodeur H264, donc le problème est bien le même. Juste qu'à ce moment là le navigateur laisse le travail à des outils externes....
Ah bah dit donc, c'est ce que Zenitram propose.

Le flash ne fait pas ses requêtes http par lui même, elles passent par le navigateur.
Le navigateur peut tout à fait, ne serait-ce que lire le content-type du fichier demandé.

Sachant qu'un certain nombre de navigateurs pour téléphone peuvent changer leur UA en truc de desktop, ça m'étonnerait fortement que les opérateurs soient assez cons pour se baser dessus. Mais je peux me tromper.

Dans le cas de la sécurité, je suis persuadé que c'est encore pire. Tu peux payer le mec tant que tu veux, si il est pas passionné par le truc, si il lit pas MISC tous les mois, il sera une vraie crêpe.
C'est surtout l'opposé de ce que t'as dit avant en fait... Il faut être et il suffit d'être passioné pour la sécurité, donc un autodidacte ça suffit ('fin de ce que je vois.).

Pour l'informatique, tu confonds autodidacte, et personne qui ont entendu parlé d'informatique pendant leurs études sans plus, et ça n'a rien rien à voir.

Je suis un autodidacte, je n'ai pas fait de programmation de tout mon cursus scolaire. (ça devrait venir l'année prochaine quand même), et je ne me reconnais pas du tout dans les exemples que tu donnes, je me considères même bon en C.
Je "comprends" de l'hexadécimal, je travaille même avec régulièrement, et pour du langage machine c'est sûr que c'est, a priori, primordial.
Un dévelopeur .Net/Java, je peux parfaitement comprendre que l'hexadécimal ne lui serve strictement à rien, et je vois pas à quoi ça sert de dénigrer les qualités de développeur de quelqu'un juste à cause de cette méconnaissance. D'accord l'hexadécimal et le binaire sont les premières choses qu'on apprend dans un cursus informatique, mais en pratique ça sert à quoi ?
Comprendre ce qu'il se passe "en dessous" ?
Les langages "modernes" sont tellement compliqués, ainsi que leurs interpréteurs/compilateurs, qu'à moins de travailler explicitement sur ces outils, il ne sert à rien de connaître leur fondement.
Et on peut exécuter un code depuis de la ROM, typiquement de la NOR, donc la théorie de la machine de Von-Neumann, elle nous fait une belle jambe.

On me signale que c'est dans les réglages de putty.

On a déjà dit OOo.

Mais en allemand, mes profs m'ont appris qu'il faut mettre les accents aux majuscules.
Le meilleur exemple que j'ai eu, c'est une interro où j'ai eu 20, et tous les autres 19.5. La différence ? Übung vs Ubung, (elle avait été très dure à trouver.)

Android utilise le framebuffer avec des ioctl maison (pour faire des blits en hard)

Toi, t'as jamais fait de matières "scientifiques".
Faire de la chimie 100% au clavier en temps réel, faut se lever de bonne heure,
pareil pour les maths.
Et pour la physique, alors là, c'est même plus la peine d'y penser.
Sans compter qu'il est plus agréable de "penser" sur une feuille (ou une tablette.) que sur un clavier à taper des formules en latex.

Je peux retirer ce que je dis alors. Mais j'ai cherché asus eee tablet sur google et la 1° chose que je vois c'est des photos avec quelqu'un qui l'utilise en tacile ...
Il me donnerait presque envie pour le coup (juste l'autonomie qui parait un peu faible pour un netbook ?)

Bon ton lien marche pas chez moi, j'ai juste la bannière en haut.
Enfin bref, je vois le titre, c'est l'asus eee tablet.
Bon donc déjà je suis tout à fait d'accord avec au dessus, une tablete pour prendre des cours, non franchement pas. Vaut mieux prendre un scanner quitte à en prendre un avec autofeeder, ça va vite.
Sinon, concernant toutes les ""tablettes"" qu'on peut voir défiler ces derniers temps, un énorme attention, ce ne sont, pour la plupart, QUE des écrans tactiles, c'est à dire que si t'y mets ton bras dessus (à moins que tu gardes ton bras en permanence surélevé ?), c'est cuit d'avance (que ce soit résistif ou capacitif). En plus les capacitifs (mais l'eee doit être résistif), ne peuvent pas vraiment être utilisés avec des stylets (bon des stylets capacitifs ça existe quand meme)
Pour prendre des notes de cours, il faut une "vraie" tablette, type Wacom (désolé de ne citer qu'une seule marque, c'est la seule que je connaisse /o\).
C'est des sylets éléctromagnétiques, qui ont des boutons pour faire gomme, et qui surtout n'interagissent pas du tout avec le bras que tu seras amenés à poser à un moment ou un autre sur la surface de l'écran.
Donc ces tablettes existent seules, mais y a des portable)s avec écrans tablette.
Je suis pas trop le milieu des tablettes, donc je connais que trois modèles et demi, le HP TC1100, une bonne vieille bestiole (qui reste globalement plus performant qu'un netbook, mais l'autonomie n'a rien à voir), les (IBM?Lenovo?) Thinkpad X61t (t pour tablet), et les dell latitude XT/XT2. (le X61T et le XT2 sont tactiles ET à stylet wacom, si on veut se la jouer kikoolol.)

Euh... source de tes benchs ?
Nan parce que le fait que le H264 comprime mieux que du theora, y a pas à tortiller, même les mecs de chez theora le disent ...

À noter que parmis les partenaire, on trouve Qualcomm et Texas Instrument, qui représentent la quasi-totalité des smartphones actuels (à l'exception bien évidement des iphone), donc ceux qui disaient que ce format ne sera pas sur les plateformes mobiles avant longtemps, ont visiblement tord. En ajoutant en plus le fait que sur les chipsets Snapdragon, (dernière génération de qualcomm), (et peut être TI ?), les DSPs ont des morceaux de firmware chargés au vol (qui utilise l'architecture firmware du noyau linux en fait), il est fort probable que ces téléphones bénéficient de mises à jours capable de lire le VP8 ! Peut être même annoncées demain, qui sait.
Bon sinon dans la liste, il y a aussi NVidia, à quand VDPAU pour VP8 ? :)

L'IPoT fait des ravages. (ou alors un an = 365jours ?)

Euh ... AndNav2 c'est pas exactement un soft de navigation libre pour android avec utilisation de cartes OSM ?
Après il dépend d'un serveur distant, et je suis pas sûr que ses sources soient incluses dans les sources.

T'as oublié un énorme problème.
L'utilisateur.
Les virus n'utilisent que très rarement des failles de sécurité, généralement ils utilisent juste l'imbécilité des utilisateurs.