Ça y est, Google livre les sources du projet Android qui, pour rappel, vise à concurrencer les OS mobile de Microsoft ou l'Iphone et dont le premier téléphone le HTC G1 sortira demain.
Elles sont pour la plupart disponible sous la licence Apache 2.0.
Pour ce qui est de les compiler il faudra télécharger un peu plus de 2GB sur le dépot Git et avoir 6GB de dispo. Il y a une explication pour la compilation sous Mac OS et ubuntu (donc les autres distribs). Il vous faudra donc Python 2.4, JDK 5.0, wxgtk (optionnel) et autres packages pour compiler.
Le petit lien qui va bien pour les télécharger : http://source.android.com/
Journal court mais j'ai essayé de mettre l'essentiel.
Journal Sources d'android disponibles.
21
oct.
2008
# En bref
Posté par Ontologia (site web personnel) . Évalué à 10.
Slide ici : http://sites.google.com/site/io/anatomy--physiology-of-an-an(...)
• Noyau Linux évidement.
• Pas de Glibc
• Quelques ajours au noyau : Système d'alarme, logger, debugger,
• • "Binder" qui facilite les communications inter processus (permet de simuler une sorte de communication objet à la dbus),
• • Gestion plus agressive de l'énergie.
• • Librairies écrite en C++ au dessus du noyau :
• • Bionic une libc maison sous licence BSD: ils expliquent qu'ils ne veulent pas de GPL en user-space !! Et bien évidemment des raisons de taille et de performances.
Implémente des services spéciaux ajoutés dans le noyau (logging). Ne supporte pas totalement POSIX.
• • Un webkit modifié pour l'adaptation aux petits écrans
• • SQLite, FreeType, SSL, ...
• • Un gestionnaire d'affichage à eux, permettant double buffering, OpenGL ES Natif, ainsi que Hardware 2D. Les surfaces sont envoyés à la puce graphique via des IPC via le Binder.
• • Gestionnaire audio maison avec mixeur
• Une HAL en user-space avec GPS, Radio, OpenGL, Bluetouth, wifi en natif
• Une VM javouille économe en mémoire, très optimisé, et permettant de simuler plusieurs machine virtuelles.
• FrameWork écrit en javouille au dessus : contenant
•• Activity Manager
•• Package Manager
•• Window Manager
•• Resource Manager
•• Content Providers
•• View System
•• Telephony Service
•• Location Service
•• Bluetooth Service
•• WiFi Service
•• USB Service
•• Sensor Service
Bref, un beau travail. On sent une grosse réflexion sur ce qu'est devenu Linux aujourd'hui.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: En bref
Posté par M . Évalué à 6.
Au dessus de la libc++/libc tu veux dire ?
Bionic une libc maison sous licence BSD: ils expliquent qu'ils ne veulent pas de GPL en user-space !!
La glibc n'est pas GPL mais lgpl...
Et bien évidemment des raisons de taille et de performances.
La uclibc convient tres bien pour la taille et aurait eu besoin de main d'oeuvre
Bref, un beau travail. On sent une grosse réflexion sur ce qu'est devenu Linux aujourd'hui.
Oui c'est un beau travail, bien qu'un peu fou (Quasiment tout redevelopper, ca veut dire qu'on a la main d'oeuvre, les compétences, pas peur d'essuyer des bugs ).
Mais maintenant la question pour le libre, c'est que ce que ca va devenir :
- d'autres projets vont réussir a récupérer des composants pour d'autres projets (comme la libc, la machine java) ?
- comment va s'effectuer la maintenance/bug report : ca ne concerne que la platforme android ou alors ils sont ouvert a d'autres utilisations
- Accepteront ils des patchs/extensions ?
[...]
[^] # Re: En bref
Posté par Elfir3 . Évalué à -1.
Quel avantage ont-ils donc à laisser sous license BSD leur lib ?
Laisser aux développeurs netbsd la possibilité de l'utiliser pour les appareils mobiles ?
Mais c'est vrai, dans la vidéo, il me semble qu'il parle bien de GPL et non de LGPL ...
[^] # Re: En bref
Posté par Erwan . Évalué à 6.
[^] # Re: En bref
Posté par Guillaume Knispel . Évalué à 6.
Quand à la modifier, c'est probablement pas non plus l'idée du siècle...
Enfin bon, Google vient de prouver qu'on peut faire un système Linux probablement largement incompatible avec tous les autres systèmes Linux qui existent. Soit. C'est pas énormément plus débile que Cisco qui code son propre Unix (légèrement buggué...) pour faire tourner ses téléphones. Oublions ce gadget useless et reprenons une activité normale.
[^] # Re: En bref
Posté par seginus . Évalué à 3.
[^] # Re: En bref
Posté par alexissoft . Évalué à 4.
Pure Java Git implementation
"allez fun flex on va réimplémenter git en java lulz."
[^] # Re: En bref
Posté par Larry Cow . Évalué à 10.
- Boah attends, trop facile, un étideur. éteudir. éditeur de sexte. Struc. Un OS, kwa. Ch'te dis.
- Wai mais attends, j'pas fini. T'même pas cap de faire un édi... truc là, en LIPS! Lisp!
[^] # Re: En bref
Posté par Clément David (site web personnel) . Évalué à 2.
[^] # Re: En bref
Posté par Aefron . Évalué à 1.
Question : vers quoi ? Des drivers proprios ou libres ? Et eux, en plein noyau ou en userland ?
De la Couche d'Abstraction Matérielle (CAM), on en a de la bonne (hald), et de la frelatée (madwifi), dans l'existant... ça peut servir à plein de choses, les HAL...
[^] # Re: En bref
Posté par Elfir3 . Évalué à 2.
En gros, d'après ce que j'ai compris de la vidéo de la conférence, il existe un module pour chaque type de matériel (libgps.so, libril.so, libaudio.so, etc) qui sont chargés à la demande, et qui sont des interfaces vers les pilotes situés en kernel space, ou dans le cas de l'audio, si le pilote audio est libre, via alsa.
Maintenant, il doit y avoir des personnes qui ont une plus grand compréhension du système que moi :)
[^] # Re: En bref
Posté par benoar . Évalué à 2.
[^] # Re: En bref
Posté par Psychofox (Mastodon) . Évalué à 2.
[^] # Re: En bref
Posté par gemegik . Évalué à 6.
Parce que c'est un noyau éprouvé et pour lequel il est relativement simple de trouver des developpeurs ?
Parce que les ingés de google ont pris celui qu'ils connaissaient le mieux ?
Parce que le noyau Linux n'est pas indiscociable de GNU/Linux, et que le principe d'UNIX est de pouvoir échanger les briques de base ?
[^] # Re: En bref
Posté par benoar . Évalué à 2.
[^] # Re: En bref
Posté par benoar . Évalué à 2.
# Peur de la GPL ?
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
On dirait qu'il ne veulent pas que l'on puisse exposer du code DRM ou interdire la tivoisation.
Cela semble assez irraisonnée comme réaction. Ou au contraire, cela fait penser que Google s'éloigne de son moto "Don't be evil".
Certe, c'est du beau code bien libre, mais je trouve qu'il dégage une mauvaise odeur par en dessous.
"La première sécurité est la liberté"
[^] # Re: Peur de la GPL ?
Posté par Nelis (site web personnel) . Évalué à 9.
Perso je préfère largement la licence Apache ou BSD à la GPL et je suis bien content que Google ait choisi ces licences.
Et puis, en réfléchissant deux secondes : si Google avait tout fait en GPL, quel fabricant de téléphone aurait accepté de libérer toutes ces sources pour utiliser Android ? Aucun ! Ici au moins, la base restera libre et pour les extensions proprio, les constructeurs font ce qu'ils veulent.
[^] # Re: Peur de la GPL ?
Posté par psychoslave__ (site web personnel) . Évalué à 3.
Mais bon, sinon, c'est trop bien le libre quand il n'offre aucune liberté à l'utilisateur final, t'as raison.
Ceci étant dis, je n'ai rien contre aucune licence libre. Je vois franchement pas l'intérêt d'avoir une base libre pour foutre du proprio par dessus. Dans ce cas je peux tout aussi bien utiliser un système proprio, je serais pas beaucoup moins dépendant du bon vouloir des fabriquants.
[^] # Re: Peur de la GPL ?
Posté par Nelis (site web personnel) . Évalué à 6.
Maintenant faut aussi remettre les choses dans l'ordre : le code qu'ils ajouteront ça ne sera pas grand chose, 95% du code (le coeur d'Android) sera libre et 5% sera proprio. Et ça, je pense que c'est déjà une grosse avancée parce qu'à par le Freerunner le monde des mobiles était plutôt du genre 100% proprio. Donc merci Google.
[^] # Re: Peur de la GPL ?
Posté par Nicolas Boulay (site web personnel) . Évalué à 0.
C'est pas la question. La question, c'est pourquoi virer la glibc ou la µlibc pour réinventer la roue uniquement pour changer la licence.
Concernant le troll licence, si toi tu préfères que certain puissent utiliser ton code sans retour au pot commun, c'est ton problème pas le mien.
"La première sécurité est la liberté"
[^] # Re: Peur de la GPL ?
Posté par CrEv (site web personnel) . Évalué à 4.
ben non, justement
Si on met un code en BSD c'est justement que ce n'est pas un problème (sinon on met une autre clause, ou une autre licence)
perso j'aime bien la BSD. non pas que je metterais tous mes softs en BSD, mais parfois la GPL me gave. Et alors ? si quelqu'un met un soft en BSD, on ne peut que lui dire merci, de la même manière que s'il avait mis en GPL, dans les deux cas il fait du libre est c'est vraiment le plus important.
[^] # Re: Peur de la GPL ?
Posté par Nelis (site web personnel) . Évalué à 3.
P't'être bien parce que ça ne correspondait pas à ce qu'ils voulaient, et qu'ils ont préférer se faire quelquechose sur mesure vu qu'ils en ont les moyens ?
Concernant le troll licence, si toi tu préfères que certain puissent utiliser ton code sans retour au pot commun, c'est ton problème pas le mien.
Exactement, je ne l'aurais pas mieux dit : c'est le problème de Google, pas le tien !
[^] # Re: Peur de la GPL ?
Posté par windu.2b . Évalué à 3.
[^] # Re: Peur de la GPL ?
Posté par Nicolas Boulay (site web personnel) . Évalué à 1.
"La première sécurité est la liberté"
# Hum 6Go?
Posté par psychoslave__ (site web personnel) . Évalué à 4.
[^] # Re: Hum 6Go?
Posté par GNUtoo . Évalué à 3.
par exemple pour openembedded malgres le fait que le tarball ou l'image a flasher prend peu de place il faut de la place pour:
*les archives des sources
*les outils natifs pour compiler le cross-compiler et compiler certains binaires(donc gcc,glibc etc...)
*les outils cross-compiles(gcc,glibc ou uclibc,les librairies etc...)
*les archives des programmes que tu as cross-compiles(ipk ou opk ) pour les distribuer(par exemple si tu crees ta distribution tu as comme pour ubuntu un mirroir ou tu met tes binaires afin de )
les outils natifs et les outils cross-compiles ne peuvent etre compresses car ils sont necessires pour compiler ton paquet...
et encore 6GO c'est pas beaucoup...avant le changement d'ABI de TMPDIR d'openembedded, mon TMPDIR me prenais environ 35GO(mais j'avais compiles beaucoup de choses tels que mplayer,wesnoth etc...)
De plus si ton image est en jffs2(image pour peripheriques MTD(c'est a dire de la flash sans interface qui abstrait le disque dur(comme par exemple mass storage) ) ) il faut savoir que le systeme de fichier jffs2 est compresse
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.