Ph Husson a écrit 2699 commentaires

G1 c'est bien mini.
Micro c'est plutot pour le HD2 et le N1 et leurs conseurs.

Pour les noyaux dont ils ont diffusé officiellement les binaires, c'est bien toutes les sources qui sont disponibles.
J'ai du mal m'exprimer dans mon commentaire encore ... Mais j'ai pas envie de réessayer.

C'est un morceau de code que qualcomm utilise dans ses drivers Windows CE, pas un morceau de Windows CE lui même.
En gros c'est une description sous forme de struct {} C des registres matériels.
Et de toutes façons, ils l'utilisent pas à la compilation, y a aucun link fait avec. (et y a pas de licence dedans en fait.)

Le noyau dont tu parles que tu voudrais avoir les sources, c'est celui issu d'android 1.6, qui n'a pas été releasé par Samsung ?
Parce que bon, les sources du noyau, je les ai sur mon disque dur et je les avais récuperé sans problème.
Si tu parles bien spécifiquement de ce noyau, ils n'ont rien fourni, donc ils sont dans leur plein droit. Seulement ce qui est redistribué doit être fourni avec les sources, vu qu'ils ont rien distribué, bam.
En ce qui concerne le support d'android 2.1, avec les sources qu'ils ont à disposition, il n'y aura aucun problème, niveau noyau, ceux qui s'amusent sur le htc hero ou htc magic ou whatever ont bien réussi. (Ils bloquent encore sur la camera, mais ils y mettent de la mauvaise volonté).
En fait, tous ces téléphones sont plus ou moins identiques, les différences sont vraiment mineures, et dans la très grande majorité des cas, tout ce qui est nécessaire existe quelque part dans un repo git de codeaurora (une organisation issue de qualcomm pour gérer tout ce qui est opensource).
Après, bien que ça existe, il faut être franchement très motivé pour trouver tous les petits morceaux. Ils doivent dépasser les 10 branches en développement, qui ont toutes leurs inconvénients et leurs défauts. Certains gèrent uniquement le msm7201A, d'autre gèrent aussi le snapdragon, mais n'ont pas les drivers video qui permettent la sortie TV, d'autres sont spécifiquement orienté vers le Nexus One, etc, etc.
Et après, y a en plus les noyaux constructeurs, plus immondes les uns que les autres. (J'ai particulièrement apprécié trouver du code issu visiblement de Windows CE dans les sources du noyau du htc hero.).

Bon bref, tout ça pour dire que même si Samsung, y met de la mauvaise volonté, c'est pas forcement les seuls, et ils sont corrects par rapport à la GPL.

Non, mais si, m'enfin ça dépend:
Déjà le "wake-on-lan", tel que normalisé ne répond pas du tout au problème: il faut que le client envoie expressément un paquet de type WoL, pas juste une requête TCP/IP classique, donc il faut que le client soit au courant du fait que le serveur ait besoin d'être réveillé.
Ensuite, en général, le réveil d'une machine est extrêmement lent, typiquement plus de 10secondes, ce qui n'est amha que moyennement acceptable vu le service demandé.
MAIS certaines architectures gèrent la mise en veille extrêmement bien, typiquement les téléphones:
Ils sont en veille 99,9% (j'ai mesuré, et encore c'était un smartphone avec push-mail activé) du temps, et se réveillent en une fraction de seconde. Le top du top dans cette histoire, c'est qu'ils se réveillent pas seulement sur des paquets Wake-On-Lan, mais sur n'importe quoi, il suffit d'un paquet rentrant pour se réveiller, et se rendormir aussi tôt si ce n'était que du bruit. Pour ceux qui veulent s'amuser, si vous avez un téléphone android, connectez le en wifi, faites le dormir (aucune appli qui tourne, et éteindre l'écran typiquement), et pingez le. Il répond au quart de tour, pourtant le téléphone continue de dormir la majorité du temps. Ah, et quand je dis que le cpu dort, c'est qu'il est complètement éteint, mais bon il a quand même un assistant qui tourne en permanence, ça aide. Il suffit de bien savoir choisir son entourage, en l'occurrence celui à consomme moins de 20mW en moyenne avec la connexion 3G ouverte.

- Android n'est pas assez homogène : pas les meme cartes graphiques, pas les mêmes résolutions d'écran, pas toujours de multi-touch
Hum, parce que la plateforme apple est mieux de ce point de vue ?
Entre l'iphone 2G, l'iphone 3G et l'iphone 3GS, et l'ipad il me semble que y en a pas 2 qui ont la même puce graphique, dont la moitié qui ne gère même pas l'OpenGL ES 2.0
Niveau résolution d'écran, si tu ne veux pas te limiter à la moitié de la gamme (et pis bon apparement y a un iphone "HD" qui s'annonce, ainsi qu'un ipad nano), bah pareil.
Mais bon, tu peux aussi limiter la gamme exploitable sous android sans problème. Si tu te limites à WVGA et HVGA, tu tappes déjà plus de 90% du marché.
Bon après niveau multitouch, ou plus généralement, périphériques d'entrée disponible, effectivement sous android pour faire des jeux c'est un vrai cauchemar. Le top étant les téléphones avec 3 boutons physiques et sans multitouch.
En ce qui concerne les PCs, je pense que c'est plus un problème d'existence d'un "market" comme apple, android and co, que du marché lui même

Avec le NDK, tu n'as accès qu'à une chose "externe", c'est l'opengles.
Donc toutes les entrées/sorties doivent être gérées dans une glue java.
Après, doit y avoir moyen de faire une glue plus ou moins universelle, et une fois qu'elle est faite, tout devrait être portable, mais pour l'instant c'est pas génial.
Celle utilisée par ScummVM vaut le coup d'oeil, mais il manque encore plein de choses, qui sont inutiles pour ScummVM, qui devrait être utile pour la plupart des applis.

Hum, à ma connaissance, un vice caché est garantie à vie, c'est à part de la garantie "normale", que j'ai toujours pas réussi à comprendre clairement ce que c'est.
Voir les espèces d'exemples fournis par la DGCCRF: http://www.dgccrf.bercy.gouv.fr/documentation/fiches_pratiqu(...) pour essayer de comprendre.
Le cas des "vices cachés" quand même assez rare, mais régulièrement y a des rappels de voitures, et c'est par crainte de devoir tout rembourser que les constructeurs font ça.

Bon, j'ai comme un sentiment de déjà vu, mais je vais recommencer.
NVidia ne contribue pas que par son driver, loin de là, même très loin de là.
NVidia est un acteur assez important niveau APIs en tout genre.
Ils ont toujours été les premiers à fournir des APIs "originales" qui sont devenus des standards: par exemple l'extension opengl texture_from_pixmap, utilisée par tous les compiz and co de nos jours.
Ils ont aussi fourni les modifications pour pouvoir utiliser Xv sur du compositing.
Si on veut développer avec une API OpenGL utilisable et avec une version à peu près à jour (ie si on veut que Linux puisse concurrent un tant soit peu windows.), on retombe toujours sur du NVIDIA.
Si on veut des fonctionnalités encore plus évoluées type 3D stéréoscopique (bon le truc où on fout des lunettes quoi), à ma connaissance y a guère que chez NVIDIA que c'est géré.
Enfin bref, AMHA, même si NVidia ne fournit pas les sources de ses drivers, ils contribuent fortement au libre de par leur présence, car ils permettent de développer/utiliser (pour) un système libre. Après c'est sûr que s'ils fournissaient un driver 100% libre ça serait encore mieux.

Euh on peut faire du multiseat avec RandR1.2 ? (et c'est une vraie question)

C'est déjà le cas, ramzswap n'utilise que la mémoire réellement utilisée.
Sinon ramzswap n'aurait aucun interêt par rapport à un ramdisk + cloop lzo + swapon dessus.

J'ai l'occasion ces temps ci de pas mal jouer avec les SoC de chez qualcomm, et bon, ils ont MMU, et MPU.
Ils ont effectivement deux CPUs complétement séparés, (plus deux dsp, et d'autres unités de calculs plus originales.), avec protections plutôt évoluée de la mémoire, aussi bien flash que RAM.
Pour rappel, les SoC qualcomm sont utilisés dans tous les smartphones HTC, et plus globalement, la très grande majorité des smartphones.
Donc pour des soucis d'économie (aussi bien économique, que de batterie et d'encombrement), toute la mémoire est partagé entre tout les périphériques, et donc il faut un dictateur pour décider qui va où.
Seulement voilà, pour une raison qui m'échappe encore, ces protections sont très facilement enlevables, et on peut accéder très facilement à la mémoire de l'arm9 (bon pas aux registres non plus m'enfin bon...).
En fait la protection tient à un bit bien placé, et c'est tout.
Donc en fait, ils se contentent d'une sécurité par l'obscurité. Ou tout du moins s'en contentaient jusque très récemment, leur nouveau SoC (snapdragon), semble utiliser d'autres méthodes de protection.
Bon et comme je code un peu à l'aveuglette (comme dit plus haut, les constructeurs ne fournissent aucunes docs), il arrive souvent que le processeur radio (qui en fait controle un peu près tout) plante. Tout simplement. Et d'après les binaires de windows mobile, il est prévu qu'il plante assez fréquement, c'est pas grave, on fait comme si de rien n'était et on continue !

Autre exemple que j'ai vu dans ma jeunesse, avec un TI Omap, sur un téléphone très peu cher (téléphone wifi+tactile+gsm à 60€ y a plusieurs années maintenant !, le twin tact de chez neuf). À l'époque j'avais très peu de connaissances sur le sujet (je n'arrivais même pas à faire booter mon propre noyau....), et pourtant, la sacro-sainte protection opérateur, a été contournée extremement facilement. Un simple fichier de configuration accessible depuis l'espace utilisateur, ou il fallait juste changer un 1 en un O. (alors que la méthode officielle de déverouillage ne marche qu'aléatoirement).

Bon bref, tout ça pour dire que le monsieur a bien raison de dire que la sécurité dans les puces radio est ridicule. Je ne connais pas les puces pour le bas de gamme, mais j'imagine que ça peut très facilement être encore pire, et je pense effectivement que le niveau de fermeture des radios est franchement trop élevé par rapport à leur niveau de sécurité effectif.
De là à faire une pile GSM complétèment libre, il y a quand même un grand pas.
Je ne connais pas l'état des connaissances sur le TI Calypso, mais je pense qu'il est beaucoup plus intéressant de documenter les comportements (aussi bien matériel que logiciel) pour montrer à quel point tout ce cirque est ridicule, et alors les constructeurs penseront peut être à s'ouvrir un peu.

Free ne met pas à jour de codec, seulement le ""décontenenceur"", ie la glue entre le DSP et le disque dur.
Le firmware du DSP reste constant, il suffit d'aller voir la doc du dsp de la freebox pour voir la liste des codecs supportés.

Les freebox pre V4 géréaient que le MPEG2, là elles étaient peut être en dur, j'en sais rien.
Mais pour la freebox HD, comme dit au dessus le H264 est beaucoup trop compliqué pour faire du décodage en dur, tout passe par un DSP.
Bon après ça n'empeche pas qu'ils devront en sortir une autre pour le SVC je pense, mais juste parce que ça demande beaucoup plus de puissance, et parce que leur fournisseur ne s'amusera sûrement pas à faire des mises à jours pour le plaisir.

Enfin, je suppose qu'un tablette type wacom ou un touchpad se règleraient quand même dans ce ficher, disparition seulement dans les cas simple probablement.
Ça marche quand même sans !
(Suffit d'avoir une bonne config udev/hald)
Y a que si on a vraiment une config très bizarre que ça marche pas

Le noyau, par contre, ne peut pas fonctionner sans la glibc .
Dit ça aux mecs qui font android.

par2 est un format de fichier qui ne fait que ça:
D'abord on crée l'archive avec l'outil de son choix, et derrière on crée des fichiers par2 de données qui permettent d'appeler un algorithme reed-salomon derrière, et on peut préciser le taux de redondance. Ce qui est bien avec cet algo c'est que le taux de récupération par rapport à l'occupation est de l'ordre de 1:1, quelque soit l'endroit où la donnée est perdue, s'il a un bloc de réparation, il peut le réparer. Il sait évidement aussi vérifier l'état d'un fichier, et sait de lui même où est-ce qu'il y a eu défaillance.
Sur ma distribution un outil pour créer ces fichiers est dans le paquet parchive2 et l'outil s'appelle d'un très original par2.

Marrant comme quelqu'un qui dit la même chose que moi mais avec un langage familié se fait pertinenter ...

De toutes façons, si on dégraissait les intermédiaires, je pense que la licence globale n'aurait même plus de sens, vu que les prix redeviendrait "honnêtes".
Sinon une licence globale à 5€/mois générerait en étant optimiste 2G€/an. Je pense effectivement qu'on serait bien loin de faire vivre toute l'industrie du disque actuelle avec si peu.

Les gens pensent à ce qu'ils ont pour le prix affiché ?
On doit pas voir les même gens dit donc.
Et en l'occurence, l'auteur du journal ne parle que de prix, et d'absoluement rien d'autre. Après s'il pensait à autre chose, je peux pas lire entre les lignes.

Et ça lui raporte plus que ça en diffusion sur radio par exemple ?
Des radios à plus du million d'auditeur ça se trouve facilement, et ça m'étonnerait assez fortement qu'il gagne plus que ça par diffusion.

Et bah non c'est pas ce que j'ai dit ...
Et visiblement vu ma note t'es pas le seul à comprendre de travers, enfin bon sur ce sujet c'est toujours comme ça ici de toutes façons, En fait, je me demande même pourquoi j'ai fait la remarque initiale sachant pertinement que ça aller donner ça en fait.

Absolument pas, relit ce que j'ai écris.

Tu mets à moitié la réponse dans ton titre:
Franchement, quelle différence entre 10€/mois et 5€/mois ? Pour la plupart des personnes qui ont un accès internet, 10€/mois c'est presque négligeable (et pour une certaine majorité ça l'est complétement.). Franchement ceux qui prétendent qu'une licence globale leur conviendrait, mais refusent les offres type (bon je dis type, mais je connais aucune offre équivalente en vrai.) Spotify sous prétexte du prix, je pense qu'ils se foutent de la gueule du monde.

En même temps, chez le grand publique, là où rajouter de la RAM suffirait, ils changent carrement d'ordinateur.