Pour lancer plusieurs VMs pour des services simples (postfix, dns, dhcp, …) je trouve que c'est du gachi d'instancier autant de choses pour juste lancer un seul service….
Alors oui c'est un peu extrême ce genre de mono tâche, mais il faudrait un juste milieu, non ?
Même si ça peux être très intéressant pour lancer une tâche dans une pool très large de VMs et les migrer entre serveurs physiques ou les créer dynamiquement, sans avoir à lancer un linux entier
Apple utiliser le conteneur MP4 comme format standard, il ne reconnait pas les AVI de base.
Je te conseille de sortir un .mp4 de ta vidéo MPEG4, elle sera reconnue sur toutes les plateformes !
Et c'est plutôt pervers de mettre du MPEG4 dans du AVI, sachant que le conteneur officiel du MPEG4 est le … MP4 …
Et avec "Aperçu", quelles sont les balises reconnues ?
Bien présent dans les distribs linux, mais pas du tout ailleur, mais on peux générer des certificats wildcard pour tous les sous-domaines de niveau inférieur !
Si je suis cette façon de penser
==>
"Le fait que ce site soit en HTML5 et CSS3 soient un standard ne garantie pas que les lecteurs le rendent correctement"
"Le fait que le français soit un standard ne garantie pas que les lecteurs le lisent correctement"
Pas de commentaires
le PDF 1.4 est conçu pour le stockage numérique de document en lecture seule pour avoir un rendu constant et identique sur toutes les plateformes sans altération dans le temps ni selon les version d'OS et de logiciels de rendus.
Je trouve aussi qu'il n'y a pas d'autre façons de mettre ce type de documents à disposition….
Un téléphone de genre avec des composants prévus avec des bus d'interconnexion rapide et évolutifs de type Thunderbolt ou USB3 et des formes capables de s'adapter aux futurs besoin, et un plastique très résistants va couter une vrai fortune !!!
De par la nature des composants, mais aussi en multipliant les process tu multiplie les couts fixes, les connecteurs, les chips d'interconnexion, …. bref un truc de designer…
Si le monde râle pour payer un téléphone avec des composants haut de gamme 600€, personne ne voudra un téléphone même écolo pour 1200€ !
Sur l'article donné à la fin de mon commentaire, j'ai trouvé :
- Future ARMv8 cores will undoubtedly be found in Apple’s iPhone and iPad
L'Article date de février 2012, soit quasiment 2 ans !
Et il détaille bien les avantages du AArch64 :
- simplification du modèle mémoire
- simplification des registres
- simplification du flow d'exécution pour monter en fréquence
- simplification du modèle d'exception
- optimisation de la mmu
- optimisation des accès
- compatibilité totale avec ARMv7
Est-ce qu'un jour on aura un Dalvik pour AArch64 ? si Nvidia bosse dessus, il n'y pas encore de patch de leur part ni d'aucun concurrent pour le support HW de linux…
Erf, pas top, au moins ils "prévoient" de le faire….
ça leur permet de forcer les concurrent à soit utiliser un backend foireux existant ou utiliser GCC qui est moins performant et surtout n'a jamais été optimisé pour faire tourner du code sur un vrai CPU…
C'est exactement ce à quoi je pense, ils montrent qu'ils sont pas loin d'avoir un SoC pour laptop à base de AArch64 !
Et à mon avis OS X compile déjà pour ARM depuis pas mal de temps, je soupçonne que TSMC va graver les puces laptop, car elles seront pas de la même taille !
Pour l'émulation x86, je suis certain qu'il existe une équipe qui à fait un traducteur X86 vers microcode comme ceux présents dans les cœurs intel, tout ça embarqué dans le SoC.
C'est long 4 ans, et il y a 4 ans, tout le monde se foutait d'avoir de l'ARM avec plus de 4 Go de RAM, les gens qui font du serveur commence que maintenant à s’intéresser à ARM pour plus de 4 Go de RAM.
Pour toi oui, mais 4 ans c'est le temps qu'il faut pour faire le design, l'intégration, le tape out, les prototypes, la validation, le soft et la mass production :-)
Et oui, il y a 4 ans, ARM a conçu le AArch64 qui est à peine utilisé aujourd'hui.
Donc il y a 4 ans, un gars chez Apple, a lancé le dev du A7, comme il y a 5 ans le dev du A6, … et ils devaient avoir une vision des performances à atteindre 4 ans à l'avance, imagine le développement aujourd'hui !
Question stupide : à quoi le 64-bit sert pour l'iPhone ayant 4 Go ou moins? On n'a pas besoin d'un CPU 64-bit pour avoir un int 64-bit. Ca ressemble plus à un premier jet pour tester pour plus tard…
Comme l'AMD64 (ou l'EMT64), ARM en a profité pour corriger une partie des faiblesses du code ARM, le +4Gbytes de mémoire n'est pas le seul but :
- virtualisation
- calcul flottant intégré
…
ce qui permet d'atteindre les 2x par rapport à un A6 avec un structure du SoC globalement identique.
Vous allez sans doute me faire passer pour un fanboy, alors que je suis ingénieur Linux Embarqué et j'aime mon métier ! (et aimerais qu'autre chose soit au dessus que cet abominable android sur les téléphones….)
Donc, oui personne n'a remarqué qu'ils ont pondu et mis en mass production de premier SoC à base de core ARM 64bit ? (AArch64 pour les intimes)
Oui, le support Linux est prêt mais les "concurrents" en sont toujours à une phase de prototypage et en chient grave, tellement que Linux ne tourne en AArch64 que sur un emulateur…
Et on apprends qu'ils ont :
- amélioré et intégré un core à base de AArch64 (il faut une armée d'ingénieurs hautement qualifiés, mes collègues en sont et on peine à sortir un SoC ~10x moins gros avec un core ARM original)
- gravé et validé ce SoC, avec tout le bazar derrière : Toolchain, Libs, Kernel ….
- porté intégralement leur OS sur le 64bit en gardant une rétro compatibilité totale des applis compilées pour du 32bit (et même ces applis compilées pour le premier iPhone…, on voir clairement l'avantage de l'Objective C)
- et ce secret n'a jamais fuité alors que ça a été 90% du boulot des 4 dernières années !
Et si leurs estimations de puissances sont vrai, ils ont améliorés la puissance CPU de x40 depuis le premier iPhone, et de x56 pour le GPU.
Leur stratégie d'intégration du développement silicium porte ses fruits, leur alliance avec TSMC va encore améliorer les choses !
Bref, c'est des tarés.
Ok ça n'a rien à voir avec le libre (sauf le support de AArch64 par LLVM) mais pour la technique, les concurrents en prennent pour leur grade !
Ce qui me gène dans le lien de "Je quitte la sécu", c'est la stigmatisation de la sécurité sociale dans son ensemble alors que le gars à juste un gros soucis avec la RSI qui fais n'importe quoi…
Alors oui, si comme lui t'as beaucoup d'argent et que tu pleures car l'état t'en prends et que tu veux te casser dans une assurance santé privée… mais qu'il ne mélange pas les cas !
Ma sécu obligatoire payée par mon salaire ne me dérange en rien !
Je dirais que c'est le principal reproche fait à Google : c'est libre mais les composants essentiels à une vrai liberté ne sont pas libres… ils gardent une maitrise de l'utilisateur à leur insu
C'est assez pervers…
Alors qu'effectivement, sous iOS/Windows Mobile/BlackBerry tu as accès à des protocoles libres et tu peux moins dépendre d'une entité tentaculaire comme Google mais tu l'as sciemment accepté en utilisant iOS par exemple, ce n'est pas à ton insu en te faisant croire que tu seras libre !
Oui, s'il a les librairies partagées qui vont bien et qu'il ne dépende pas d'options dans le noyau que les téléphone n'ont pas forcément vu qu'android ne les utilise pas…
Mais tu le vois bien, c'est des problématiques de configuration et de fichiers disponibles ou pas dans l'espace utilisateur.
Mais dans tous les cas :
- tu prends un debian pour x86
- tu compiles ton Hello World qui sort du texte sur la sortie standard en statique pour ne dépendra de rien d'autre que le kernel et le processeur
- tu prends une appli "Terminal" ou console sur Android x86, tu copie le binaire, il s'exécutera sans soucis
Aprés, pour faire du graphique, tu vas dépendre de l'affichage graphique de la distribution (X.org ou SurfaceFlinger), donc rien à voir avec le noyau.
Debian, Ubuntu, Fedora, …. utilisent une version dérivée du noyau Linux avec des patchs et des options spécifiques.
De la même manière les téléphones Android utilisent aussi une version dérivée avec en plus des patchs spécifiques à la distribution Android ainsi que le support du processeur mobile.
Linux reste Linux car l'API entre le système et le noyau est strictement la même entre un noyau Linux de Debian pour x86 et un téléphone sous x86, les seules différences concernent les accès supplémentaires ajoutés pour Android.
Canonical à été cité, car ils ont récupérés un noyau compilé pour Android (Linux+Patch Android+Support SoC) et ont fait tourner Ubuntu avec le démon graphique de Android.
Donc, oui c'est Linux et oui tu peux faire tourner un APK SI-ET-SEULEMENT si tu as une distribution Android (ou compatible) et que le noyau supporte les extensions Android (Wakelock, Debug, …) et inversement, tu peux très bien faire tourner Debian sur un noyau compilé pour un téléphone.
Un exemple :
- Je suis développeur Linux sur des Décodeurs Satellite
- Je porte un noyau sur le processeur vidéo utilisé, donc un noyau "Vanilla" de kernel.org avec un patch pour supporter le processeur
- Notre application tourne sans distribution, uniquement avec une base Busybox pour lancer le binaire
- Avec 2/3 patchs sur noyau, Android fonctionne
- Sans patchs, Debian ou Ubuntu fonctionne
C'est la même chose pour un téléphone. Et c'est la raison pour laquelle Stallman dit "GNU/Linux" et que les téléphones sont sous "Android/Linux" ou "iOS/Darwin" ou "WindowsRT/NT" …
# Busybox
Posté par superna (site web personnel) . En réponse au journal Systemd va gagner une console système, un bootsplash et un login-screen. Évalué à 2.
Ce sera en somme un super busybox ?
# un OS entier dans une VM c'est un peu con...
Posté par superna (site web personnel) . En réponse au journal OSv : l'OS pour les nuages. Évalué à 6.
Pour lancer plusieurs VMs pour des services simples (postfix, dns, dhcp, …) je trouve que c'est du gachi d'instancier autant de choses pour juste lancer un seul service….
Alors oui c'est un peu extrême ce genre de mono tâche, mais il faudrait un juste milieu, non ?
Même si ça peux être très intéressant pour lancer une tâche dans une pool très large de VMs et les migrer entre serveurs physiques ou les créer dynamiquement, sans avoir à lancer un linux entier
# Mac OS
Posté par superna (site web personnel) . En réponse au journal Intégrer des vidéos dans des fichiers PDF. Évalué à 3.
Apple utiliser le conteneur MP4 comme format standard, il ne reconnait pas les AVI de base.
Je te conseille de sortir un .mp4 de ta vidéo MPEG4, elle sera reconnue sur toutes les plateformes !
Et c'est plutôt pervers de mettre du MPEG4 dans du AVI, sachant que le conteneur officiel du MPEG4 est le … MP4 …
Et avec "Aperçu", quelles sont les balises reconnues ?
# CACert
Posté par superna (site web personnel) . En réponse au journal Auto-hébergement et sécurisation des accès via HTTPS. Évalué à 7. Dernière modification le 07 novembre 2013 à 14:29.
Bien présent dans les distribs linux, mais pas du tout ailleur, mais on peux générer des certificats wildcard pour tous les sous-domaines de niveau inférieur !
# chocolatey
Posté par superna (site web personnel) . En réponse au journal Quelques outils pour Windows. Évalué à 5.
Quand je vois la ligne de commande :
@powershell -NoProfile -ExecutionPolicy unrestricted -Command "iex ((new-object net.webclient).DownloadString('https://chocolatey.org/install.ps1'))" && SET PATH=%PATH%;%systemdrive%\chocolatey\bin
Wow !
à comparer avec la commande de Homebrew sur mac :
ruby -e "$(curl -fsSL https://raw.github.com/mxcl/homebrew/go)"
Bah c'est pas pareil quoi !
Les WindowsBoyzFanz diront : "Oui mais tu vois c'est du C# direct dans la console qui permet de faire des choses trop belles toussa toussa"
Oui, peut être, mais dans un cmd.exe qui ressemble à un minitel… et le minitel était même mieux !
# CBC
Posté par superna (site web personnel) . En réponse au message CryptoJS, PyCrypto et OpenSSL sont dans un bateau…. Évalué à 2.
Si j'étais toi j'utiliserais CBC, qui est plus simple. Je doute que CFB ne t'apporte grand chose….
Il y a peut être une différence d'encodage du plaintext…
[^] # Re: PDF
Posté par superna (site web personnel) . En réponse au journal Qualite des disques blu-ray enregistrables pour l’archivage des donnees numeriques. Évalué à 10.
Superbe façon de penser !
Si je suis cette façon de penser
==>
"Le fait que ce site soit en HTML5 et CSS3 soient un standard ne garantie pas que les lecteurs le rendent correctement"
"Le fait que le français soit un standard ne garantie pas que les lecteurs le lisent correctement"
Pas de commentaires
le PDF 1.4 est conçu pour le stockage numérique de document en lecture seule pour avoir un rendu constant et identique sur toutes les plateformes sans altération dans le temps ni selon les version d'OS et de logiciels de rendus.
Je trouve aussi qu'il n'y a pas d'autre façons de mettre ce type de documents à disposition….
[^] # Re: PDF
Posté par superna (site web personnel) . En réponse au journal Qualite des disques blu-ray enregistrables pour l’archivage des donnees numeriques. Évalué à 10. Dernière modification le 15 octobre 2013 à 15:28.
Si c'est un PDF 1.4, au contraire c'est bien !
Je ne comprends pas, tu voudrais quoi ?
Du LaTeX ? du Postscript ? du OpenDocument qui ne rends pas pareil sur chaque version de chacune des suites ?
[^] # Re: Forum!
Posté par superna (site web personnel) . En réponse au message Free Electrons recrute. Évalué à 7.
surtout pour leur attachement à tout publier upstream !
# Prix
Posté par superna (site web personnel) . En réponse au journal Un smartphone fait de pièces standardes pour lutter contre le gâchis écologique. Évalué à 2.
Un téléphone de genre avec des composants prévus avec des bus d'interconnexion rapide et évolutifs de type Thunderbolt ou USB3 et des formes capables de s'adapter aux futurs besoin, et un plastique très résistants va couter une vrai fortune !!!
De par la nature des composants, mais aussi en multipliant les process tu multiplie les couts fixes, les connecteurs, les chips d'interconnexion, …. bref un truc de designer…
Si le monde râle pour payer un téléphone avec des composants haut de gamme 600€, personne ne voudra un téléphone même écolo pour 1200€ !
[^] # Re: Hardware
Posté par superna (site web personnel) . En réponse au journal Chronique d'un gros flop en perspective. Évalué à 2.
Sur l'article donné à la fin de mon commentaire, j'ai trouvé :
- Future ARMv8 cores will undoubtedly be found in Apple’s iPhone and iPad
L'Article date de février 2012, soit quasiment 2 ans !
Et il détaille bien les avantages du AArch64 :
- simplification du modèle mémoire
- simplification des registres
- simplification du flow d'exécution pour monter en fréquence
- simplification du modèle d'exception
- optimisation de la mmu
- optimisation des accès
- compatibilité totale avec ARMv7
Est-ce qu'un jour on aura un Dalvik pour AArch64 ? si Nvidia bosse dessus, il n'y pas encore de patch de leur part ni d'aucun concurrent pour le support HW de linux…
[^] # Re: Hardware
Posté par superna (site web personnel) . En réponse au journal Chronique d'un gros flop en perspective. Évalué à 1.
La puissance sur un SoC de téléphone, on ne sait pas ce que donnerait le même core mis 4 fois à 2GHz avec de la DDR4 et un GPU de classe desktop !
[^] # Re: 599$/€
Posté par superna (site web personnel) . En réponse au journal Chronique d'un gros flop en perspective. Évalué à 1.
Sur l'Apple Store, on ne connait pas les prix nus de Free Mobile par exemple.
Pour l'iPhone 5, ils étaient plus bas.
[^] # Re: Hardware
Posté par superna (site web personnel) . En réponse au journal Chronique d'un gros flop en perspective. Évalué à 0.
Erf, pas top, au moins ils "prévoient" de le faire….
ça leur permet de forcer les concurrent à soit utiliser un backend foireux existant ou utiliser GCC qui est moins performant et surtout n'a jamais été optimisé pour faire tourner du code sur un vrai CPU…
Bref, c'est pas sympas, mais c'est le jeux…
[^] # Re: Hardware
Posté par superna (site web personnel) . En réponse au journal Chronique d'un gros flop en perspective. Évalué à 0.
C'est exactement ce à quoi je pense, ils montrent qu'ils sont pas loin d'avoir un SoC pour laptop à base de AArch64 !
Et à mon avis OS X compile déjà pour ARM depuis pas mal de temps, je soupçonne que TSMC va graver les puces laptop, car elles seront pas de la même taille !
Pour l'émulation x86, je suis certain qu'il existe une équipe qui à fait un traducteur X86 vers microcode comme ceux présents dans les cœurs intel, tout ça embarqué dans le SoC.
[^] # Re: Hardware
Posté par superna (site web personnel) . En réponse au journal Chronique d'un gros flop en perspective. Évalué à 9.
Pour toi oui, mais 4 ans c'est le temps qu'il faut pour faire le design, l'intégration, le tape out, les prototypes, la validation, le soft et la mass production :-)
Et oui, il y a 4 ans, ARM a conçu le AArch64 qui est à peine utilisé aujourd'hui.
Donc il y a 4 ans, un gars chez Apple, a lancé le dev du A7, comme il y a 5 ans le dev du A6, … et ils devaient avoir une vision des performances à atteindre 4 ans à l'avance, imagine le développement aujourd'hui !
Comme l'AMD64 (ou l'EMT64), ARM en a profité pour corriger une partie des faiblesses du code ARM, le +4Gbytes de mémoire n'est pas le seul but :
- virtualisation
- calcul flottant intégré
…
ce qui permet d'atteindre les 2x par rapport à un A6 avec un structure du SoC globalement identique.
Je te laisse lire ça :h ttp://www.realworldtech.com/arm64/
Et contrairement à AMD, ça reste un SoC et ils ont surement aussi gagné en consommation, contrairement à ADM et Intel ;-)
# Hardware
Posté par superna (site web personnel) . En réponse au journal Chronique d'un gros flop en perspective. Évalué à 10.
Vous allez sans doute me faire passer pour un fanboy, alors que je suis ingénieur Linux Embarqué et j'aime mon métier ! (et aimerais qu'autre chose soit au dessus que cet abominable android sur les téléphones….)
Donc, oui personne n'a remarqué qu'ils ont pondu et mis en mass production de premier SoC à base de core ARM 64bit ? (AArch64 pour les intimes)
Oui, le support Linux est prêt mais les "concurrents" en sont toujours à une phase de prototypage et en chient grave, tellement que Linux ne tourne en AArch64 que sur un emulateur…
Et on apprends qu'ils ont :
- amélioré et intégré un core à base de AArch64 (il faut une armée d'ingénieurs hautement qualifiés, mes collègues en sont et on peine à sortir un SoC ~10x moins gros avec un core ARM original)
- gravé et validé ce SoC, avec tout le bazar derrière : Toolchain, Libs, Kernel ….
- porté intégralement leur OS sur le 64bit en gardant une rétro compatibilité totale des applis compilées pour du 32bit (et même ces applis compilées pour le premier iPhone…, on voir clairement l'avantage de l'Objective C)
- et ce secret n'a jamais fuité alors que ça a été 90% du boulot des 4 dernières années !
Et si leurs estimations de puissances sont vrai, ils ont améliorés la puissance CPU de x40 depuis le premier iPhone, et de x56 pour le GPU.
Leur stratégie d'intégration du développement silicium porte ses fruits, leur alliance avec TSMC va encore améliorer les choses !
Bref, c'est des tarés.
Ok ça n'a rien à voir avec le libre (sauf le support de AArch64 par LLVM) mais pour la technique, les concurrents en prennent pour leur grade !
# Stigmatisation de la "sécu"
Posté par superna (site web personnel) . En réponse au journal Quitter la sécurité sociale. Évalué à 10.
Ce qui me gène dans le lien de "Je quitte la sécu", c'est la stigmatisation de la sécurité sociale dans son ensemble alors que le gars à juste un gros soucis avec la RSI qui fais n'importe quoi…
Alors oui, si comme lui t'as beaucoup d'argent et que tu pleures car l'état t'en prends et que tu veux te casser dans une assurance santé privée… mais qu'il ne mélange pas les cas !
Ma sécu obligatoire payée par mon salaire ne me dérange en rien !
[^] # Re: Le PDF d'accopagnement est loin d'être fait en libriste
Posté par superna (site web personnel) . En réponse au journal L'éducation nationale publie des polices de caractères cursive libres... de diffusion. Évalué à 1.
A choisir, je préfère que ce soir fait avec un outil pro de design de documents plutôt que la débile "Adobe Acrobat with Microsoft Office"….
Quand je reçois des datasheet et des document de plusieurs centaines de pages édités et sortis en PDF avec Office, je meurs….
[^] # Re: Troll : merci Apple
Posté par superna (site web personnel) . En réponse au journal C++11 : sur le fil. Évalué à 1.
Pour ARM, apple utilise LLVM pour compiler tout son système et bientôt toutes les applications par défaut !
Jusqu'à présent, Google ne s'en sers pas autant !
Donc oui Apple pousse surtout le support ARM…
[^] # Re: Un peu de sérieux nous sommes lundi...
Posté par superna (site web personnel) . En réponse au journal Android : retour d'expérience. Évalué à 1.
How to run Debian or Ubuntu GNU/Linux on your Android : http://whiteboard.ping.se/Android/Debian
C'est déjà faisable avec un téléphone routé.
[^] # Re: Android et les protocoles propriétaires
Posté par superna (site web personnel) . En réponse au journal Android : retour d'expérience. Évalué à 3.
Je dirais que c'est le principal reproche fait à Google : c'est libre mais les composants essentiels à une vrai liberté ne sont pas libres… ils gardent une maitrise de l'utilisateur à leur insu
C'est assez pervers…
Alors qu'effectivement, sous iOS/Windows Mobile/BlackBerry tu as accès à des protocoles libres et tu peux moins dépendre d'une entité tentaculaire comme Google mais tu l'as sciemment accepté en utilisant iOS par exemple, ce n'est pas à ton insu en te faisant croire que tu seras libre !
[^] # Re: Un peu de sérieux nous sommes lundi...
Posté par superna (site web personnel) . En réponse au journal Android : retour d'expérience. Évalué à 3.
Oui, s'il a les librairies partagées qui vont bien et qu'il ne dépende pas d'options dans le noyau que les téléphone n'ont pas forcément vu qu'android ne les utilise pas…
Mais tu le vois bien, c'est des problématiques de configuration et de fichiers disponibles ou pas dans l'espace utilisateur.
Mais dans tous les cas :
- tu prends un debian pour x86
- tu compiles ton Hello World qui sort du texte sur la sortie standard en statique pour ne dépendra de rien d'autre que le kernel et le processeur
- tu prends une appli "Terminal" ou console sur Android x86, tu copie le binaire, il s'exécutera sans soucis
Aprés, pour faire du graphique, tu vas dépendre de l'affichage graphique de la distribution (X.org ou SurfaceFlinger), donc rien à voir avec le noyau.
[^] # Re: Tor
Posté par superna (site web personnel) . En réponse au journal Bitmessage : envoi de messages chiffrés en p2p. Évalué à 1.
Ouverture de ports et accès pair à pair sans contraintes sur à un firewall ?
[^] # Re: Un peu de sérieux nous sommes lundi...
Posté par superna (site web personnel) . En réponse au journal Android : retour d'expérience. Évalué à 5.
Bon, on va clarifier les choses :
Debian, Ubuntu, Fedora, …. utilisent une version dérivée du noyau Linux avec des patchs et des options spécifiques.
De la même manière les téléphones Android utilisent aussi une version dérivée avec en plus des patchs spécifiques à la distribution Android ainsi que le support du processeur mobile.
Linux reste Linux car l'API entre le système et le noyau est strictement la même entre un noyau Linux de Debian pour x86 et un téléphone sous x86, les seules différences concernent les accès supplémentaires ajoutés pour Android.
Canonical à été cité, car ils ont récupérés un noyau compilé pour Android (Linux+Patch Android+Support SoC) et ont fait tourner Ubuntu avec le démon graphique de Android.
Donc, oui c'est Linux et oui tu peux faire tourner un APK SI-ET-SEULEMENT si tu as une distribution Android (ou compatible) et que le noyau supporte les extensions Android (Wakelock, Debug, …) et inversement, tu peux très bien faire tourner Debian sur un noyau compilé pour un téléphone.
Un exemple :
- Je suis développeur Linux sur des Décodeurs Satellite
- Je porte un noyau sur le processeur vidéo utilisé, donc un noyau "Vanilla" de kernel.org avec un patch pour supporter le processeur
- Notre application tourne sans distribution, uniquement avec une base Busybox pour lancer le binaire
- Avec 2/3 patchs sur noyau, Android fonctionne
- Sans patchs, Debian ou Ubuntu fonctionne
C'est la même chose pour un téléphone. Et c'est la raison pour laquelle Stallman dit "GNU/Linux" et que les téléphones sont sous "Android/Linux" ou "iOS/Darwin" ou "WindowsRT/NT" …