Faux problème. Le même argument nous est ressorti à propos des puces wifi, alors que, dans la pratique, un pilote libre s'en accomode bien. Un code privateur peut aussi être détourné et n'offre donc pas plus de garanties. Maintenant, si quelqu'un veut innonder ses voisins d'ondes électromagnétiques, qu'il bidouille son four à micro-ondes, cela à plus de chances d'être efficace.
J'avais pas vu qu'on m'avait répondu sur ce point avant aussi; j'ai dû mal m'exprimer. Je sais bien que c'est un faux problème, je dis que c'est celui qu'invoquent les opérateurs téléphoniques (sous prétexte évident de contrôle).
Effectivement, cela est fort regrettable. On prend un noyau gpl2 tivo-isable, des libs apaches et on réécrit une pseudo jvm dans cet unique but. Et après, certains osent encore peindre Google en chevalier blanc, défenseur du libre.
C'est pas ma vision non plus, mais si Google, dans son désir purement capitaliste, utilise le logiciel libre et en distribue, je ne vais pas me plaindre: j'aimerais que Microsoft ou Apple le fassent (vraiment) aussi. S'ils sortent tout (ou presque) Android sous ASL je serai bien content. Comme je l'ai dit, c'est une optique beaucoup plus "open source" que "free software", mais rien n'empêche que légalement, la majeure partie du code devrait être libre.
Avoir de la doc, c'est un minimum pour tout SDK. L'accès aux sources, je vois pas trop à quoi il sert, si ce n'est pour leur envoyer gracieusement un patch en attendant qu'ils veulent bien l'intégrer.
La doc, c'est un évidemment un minimum -- on peut espérer mieux que celle de J2ME, mais il y aura aussi un soutien aux utilisateurs (développeurs) par Google, c'est déjà le cas d'ailleurs. C'est non négligeable qu'il y ait la volonté d'une grosse boite, active, derrière, plutôt que 3 développeurs surchargés qui répondent de temps en temps à un mail pour un problème bien spécifique et de façon absconse.
En ce qui concerne l'accès au code, il indique précisément comment fonctionne le bousin: si tu veux remplacer un composant, par exemple le "dialer" (numéroteur?) par défaut, tu peux repartir de celui de Google (si t'as le code)... il y a des interfaces à respecter, etc, pour un petit composant c'est facile, pour d'autres plus difficiles. Enfin en tant qu'utilisateur si tu veux modifier un aspect non paramétrable sur TON téléphone, avoir le code c'est génial, et à mon avis plus utile que pour une application de bureau, parce que sur un portable l'interface est limitée et donc plus importante.
Avec le buzz que ça a fait, fait, va faire, c'est bien parti... Dommage que les développeurs (developpers, developpers, developpers ! (c) ms) préfèrent attendre une bannale api java made in Google que de s'investir un tant soit peu sur une plateforme vraiment libre. Quant à l'utilisateur, il n'a rien à dire (comme toujours...) :-/
Si on fait confiance aux promesses de Google (moi je dis c'est du 70% ;)), ça sera une api libre. Mais honnêtement elle est pas si banale, elle est pas mal, elle existe, elle est uniformisée et surtout, il y a une machine commerciale derrière.
J'ai essayé Android déjà (à travers l'émulateur du SDK), et même si ça n'a rien d'exceptionnel pour l'instant, le design derrière est bien, avec un peu de boulot ça devrait s'améliorer.
Ce qui me motive le plus, c'est l'idée que Google pourrait parvenir à changer la donne en matière de téléphonie portable; le modèle actuel est complètement dépassé. Si l'iPhone n'a pas Skype, c'est parce que AT&T a refusé .. les comm' c'est leur fond de commerce. Mais sur un téléphone libre, où on peut utiliser le micro, changer le dialer, etc... rien n'empêchera d'avoir un client SIP ou autre (personnellement je préférerais du Jingle, conferencing over XMPP). Les opérateurs téléphoniques sont extrêmement conservateurs sur ce point, ils ont déjà perdu les communications fixes, et le portable c'est leur vache à lait (musique, sms/mms, communications)... alors que d'un point de vue technologique, tout pourrait être remplacé par une simple connexion 3G.
Je pense que Google va chambouler la situation, c'est juste que je ne sais pas encore comment :). J'attends de voir.
[^] # Re: Et bientôt ...
Posté par smc . En réponse au journal Le premier téléphone Android pour bientôt. Évalué à 2.
J'avais pas vu qu'on m'avait répondu sur ce point avant aussi; j'ai dû mal m'exprimer. Je sais bien que c'est un faux problème, je dis que c'est celui qu'invoquent les opérateurs téléphoniques (sous prétexte évident de contrôle).
Effectivement, cela est fort regrettable. On prend un noyau gpl2 tivo-isable, des libs apaches et on réécrit une pseudo jvm dans cet unique but. Et après, certains osent encore peindre Google en chevalier blanc, défenseur du libre.
C'est pas ma vision non plus, mais si Google, dans son désir purement capitaliste, utilise le logiciel libre et en distribue, je ne vais pas me plaindre: j'aimerais que Microsoft ou Apple le fassent (vraiment) aussi. S'ils sortent tout (ou presque) Android sous ASL je serai bien content. Comme je l'ai dit, c'est une optique beaucoup plus "open source" que "free software", mais rien n'empêche que légalement, la majeure partie du code devrait être libre.
Avoir de la doc, c'est un minimum pour tout SDK. L'accès aux sources, je vois pas trop à quoi il sert, si ce n'est pour leur envoyer gracieusement un patch en attendant qu'ils veulent bien l'intégrer.
La doc, c'est un évidemment un minimum -- on peut espérer mieux que celle de J2ME, mais il y aura aussi un soutien aux utilisateurs (développeurs) par Google, c'est déjà le cas d'ailleurs. C'est non négligeable qu'il y ait la volonté d'une grosse boite, active, derrière, plutôt que 3 développeurs surchargés qui répondent de temps en temps à un mail pour un problème bien spécifique et de façon absconse.
En ce qui concerne l'accès au code, il indique précisément comment fonctionne le bousin: si tu veux remplacer un composant, par exemple le "dialer" (numéroteur?) par défaut, tu peux repartir de celui de Google (si t'as le code)... il y a des interfaces à respecter, etc, pour un petit composant c'est facile, pour d'autres plus difficiles. Enfin en tant qu'utilisateur si tu veux modifier un aspect non paramétrable sur TON téléphone, avoir le code c'est génial, et à mon avis plus utile que pour une application de bureau, parce que sur un portable l'interface est limitée et donc plus importante.
Avec le buzz que ça a fait, fait, va faire, c'est bien parti... Dommage que les développeurs (developpers, developpers, developpers ! (c) ms) préfèrent attendre une bannale api java made in Google que de s'investir un tant soit peu sur une plateforme vraiment libre. Quant à l'utilisateur, il n'a rien à dire (comme toujours...) :-/
Si on fait confiance aux promesses de Google (moi je dis c'est du 70% ;)), ça sera une api libre. Mais honnêtement elle est pas si banale, elle est pas mal, elle existe, elle est uniformisée et surtout, il y a une machine commerciale derrière.
J'ai essayé Android déjà (à travers l'émulateur du SDK), et même si ça n'a rien d'exceptionnel pour l'instant, le design derrière est bien, avec un peu de boulot ça devrait s'améliorer.
Ce qui me motive le plus, c'est l'idée que Google pourrait parvenir à changer la donne en matière de téléphonie portable; le modèle actuel est complètement dépassé. Si l'iPhone n'a pas Skype, c'est parce que AT&T a refusé .. les comm' c'est leur fond de commerce. Mais sur un téléphone libre, où on peut utiliser le micro, changer le dialer, etc... rien n'empêchera d'avoir un client SIP ou autre (personnellement je préférerais du Jingle, conferencing over XMPP). Les opérateurs téléphoniques sont extrêmement conservateurs sur ce point, ils ont déjà perdu les communications fixes, et le portable c'est leur vache à lait (musique, sms/mms, communications)... alors que d'un point de vue technologique, tout pourrait être remplacé par une simple connexion 3G.
Je pense que Google va chambouler la situation, c'est juste que je ne sais pas encore comment :). J'attends de voir.