XMPP/Jabber contacts that you have saved in GoogleTalk will not show up in Hangouts app
Adding new XMPP/Jabber contacts in new Hangouts app will add them as email only contacts
XMPP/Jabber contacts can not send IM to Hangouts user (it fails to deliver with error)
Gmail account will appear online to XMPP/Jabber contacts when Hangout app is logged in (presumably through/via Gmail.com/GoogleTalk)
If the same gmail user logs into www.gmail.com they can still IM XMPP/Jabber contacts (Google notes that talk will be superceded by Hangouts eventually)
As-tu utilisé Talk ou Hangouts ? Hangouts n’est pas encore déployé sur tous les gmail. Et quand on se connecte via XMPP à son compte il semblerai qu’on utilise Talk.
Peux-tu communiquer avec quelqu’un connecté à Hangouts utilisant la nouvelle appli Android ? Ou le chat intégré à Google+?
Par contre, il est effectivement possible que cette situation soit temporaire, comme sous entendu dans le journal. Seulement, on a aucune garantie de Google que ça soit effectivement le cas.
Dans cet article il critique aussi fortement l’approche initiale de Canonical concernant son fork et appropriation de libhybris. Ils sont depuis rentrés dans le rang, mais l’origine même de Mir n’a plus aucun fondement maintenant qu’il est possible de tout faire avec Wayland+libhybris+android en libre.
Dans le second cas ça serait révolutionnaire, car on aurait dans des smartphones et tablettes une stack graphique 100% libre. À noter aussi, la frénésie d’embauche de développeurs graphique Linux d’Intel n’est peut-être pas un hasard…
Il me semble qu’il s’agit de commandes vocales, et non de reconnaissance vocale (sauf pour la recherche). Ces commandes sont assez basiques, et volontairement restreintes, et seraient donc analysées hors ligne.
Non, bien évidemment. La première chose à faire pour bidouiller tranquillement un système android étant d’installer son binaire busybox (comme décrit dans le lien plus haut).
C’est intéressant, mais je pense que la BSD est suffisante pour utiliser le même principe de game theory, à partir du moment où le projet évolue suffisamment rapidement.
L’intérêt est alors non pas de garantir que les autres pourront utiliser sans reverser (ils le peuvent), mais de garantir qu’on ne prendra pas assez de retard, et que les coûts de maintenance ne vont pas exploser. Ainsi, si un acteur décide de se la jouer solo, il sera pénalisé par rapport aux autres acteurs qui eux continuent d’avancer, et ses couts de maintenance vont exploser s’il décide de garder sa partie proprio secrète, sans la proposer à upstream. Ça ne marche que pour les projets dynamiques, pour lesquels le code est une cible mouvante permanente. Il faut aussi qu’il y aient suffisamment de gros acteurs (> 3) qui contribuent pour que ça marche.
Ce n’est pas aussi simple car l’objectif de Samsung est de mettre ça dans des appareils mobiles qui utilisent souvent une eMMC. Certaines des ces eMMC sont faites par Samsung, et dans tous les cas, l’ensemble des propriétés des FTL de ces cartes sont connues par Samsung… C’est donc un avantage, car les deux (le FS et le FTL de la carte) s’emboîtent alors très bien. Il y a très peu d’amplification d’écriture par exemple.
Là où le bas blesse c’est lorsqu’on veut utiliser F2FS sur une carte SD dont on ne connaît pas les propriétés (les tailles de blocs), et ben ça n’est plus du tout efficace. Et rien n’est prévu dans le filesystem pour "découvrir" les paramètres de la SD sous-jacente, il faut le tuner selon les propriété de la carte, ce qui n’est pas un problème pour Samsung, mais un peu plus pour un bidouilleur dans son coin.
J’ai reprit une partie de ce qui est expliqué ici: http://lwn.net/Articles/518988/
Ce qui est vraiment très puissant dans Android 4.2 c’est de taper avec des gestes, à la Swype. Ça marche très bien, voire mieux que l’original. Idéal pour une seule main. Et quand on veut taper "normalement" (lentement) c’est possible.
C’est exact, le moteur et tout est libre (et très puissant depuis 4.2). Mais pas les données. Il n’y a pas de dico de complétion/correction dans AOSP à ma connaissance.
Mais je suis d’accord, la meilleure solution est de demander à ce qu’il soit intégré dans AOSP. Je ne suis pas au courant d’une telle initiative.
Il faudrait également rajouter une keymap dans Android pour les claviers externes, pour le cas ou l’on branchez un clavier physique via USB par exemple.
Si tout cela te semble évident (à moi aussi), c’est peut-être parce que la cible (LinuxFr) n’est pas la bonne. Mais ce n’est pas une raison pour ne pas résumer toutes ces techniques fondamentales dans un court article qu’on sera bien content d’envoyer aux béotiens.
Le travail réalisé consiste à sortir la description du matériel du noyau et à la reporter dans un fichier texte qui lui sera transmis lors du démarrage
En gros, le fichier de description est bien un fichier texte(platforme.dts), mais il est compilé en une structure de donnée binaire (platforme.dtb), et c’est ce qui est passé par le bootloader. Pour le cas où le bootloader est trop vieux et ne supporte pas le passage de dtb, celle-ci peut-être concaténée à l’image noyau, et celui-ci la charge de lui même. Mais on perd l’intérêt d’avoir une seule image pour plusieurs plateformes.
Pour certains oui. Ce n’est en tous cas pas le cas de tous les développeurs impliqués dans la pile graphique libre.
Ce GPU est particulier, et différent de tous les autres dans la mesure où sont "firmware" tourne sur un processeur qui a plus de charge que ce qui se fait habituellement. Habituellement, le firmware s’occupe de taches annexes comme la gestion de l’énergie, ou décharger le CPU de quelques opérations lourdes. Ici, l’intégralité du driver est sur un autre processeur, dans ce qu’on appelle "firmware". Firmware qui contient l’implémentation OpenGLES ou encore le compilateur de shaders (!). Ce dernier est l’un des composant les plus secrets des GPU.
Et il m’est d’avis que ce n’est pas dû au hasard. Broadcom est un des derniers entrants dans le domaine des SoC, aussi ça ne m’étonnerai pas qu’au moment du design du GPU, ils aient fait ce choix en pensant aux drivers "libres" sous Linux. Ou alors ils voulaient vraiment que le CPU fasse un minimum de choses pour minimiser la consommation, mais j’en doute fort.
Donc sans accès aux basses couches du GPU, ce driver est fort peu utile vu qu’on ne peut écrire de driver Mesa. Ça veut dire qu’on est tributaire du bon vouloir de Broadcom pour corriger les bugs de l’implémentation, améliorer les performances, rajouter des extensions OpenGL(ES), ou s’assurer que la mémoire mappée par le GPU ne vas écraser notre bon vieux sudo (raisons de sécurité).
[^] # Re: Idée
Posté par Aissen . En réponse au journal La gestion de courriels est-elle adulte ou encore au stade de l'enfance ?. Évalué à 4.
Oui, cette nouvelle fonctionnalité est le sujet de ce journal. Bravo pour ta lecture approfondie.
[^] # Re: Mwai
Posté par Aissen . En réponse au journal Google Hangouts remplace Talk: la fin de la fédération XMPP ?. Évalué à 2.
Pour plus de détails, regarde ce post d’un ami de Microsoft:
http://windowspbx.blogspot.fr/2013/05/hangouts-wont-hangout-with-other.html
Je cite:
[^] # Re: Mwai
Posté par Aissen . En réponse au journal Google Hangouts remplace Talk: la fin de la fédération XMPP ?. Évalué à 4.
As-tu utilisé Talk ou Hangouts ? Hangouts n’est pas encore déployé sur tous les gmail. Et quand on se connecte via XMPP à son compte il semblerai qu’on utilise Talk.
Peux-tu communiquer avec quelqu’un connecté à Hangouts utilisant la nouvelle appli Android ? Ou le chat intégré à Google+?
Par contre, il est effectivement possible que cette situation soit temporaire, comme sous entendu dans le journal. Seulement, on a aucune garantie de Google que ça soit effectivement le cas.
[^] # Re: Weston utilisable...
Posté par Aissen . En réponse à la dépêche X.Org est mort, vive Wayland ! (2). Évalué à 3.
Pour apporter de l’eau au moulin de cedric, une annonce officielle du projet E concernant le support de Wayland vs Mir:
https://phab.enlightenment.org/phame/live/1/post/enlightenment_and_efl_backing_wayland/
J’aimerai ajouter une révolution qui a été lachée par Carsten Munk, l’auteur de libhybris, qui détruit les fondements même technologiques de Mir: la possibilité d’utiliser des drivers graphiques proprio android avec wayland grace à libhybris (https://github.com/libhybris/libhybris ):
http://mer-project.blogspot.kr/2013/04/wayland-utilizing-android-gpu-drivers.html
Dans cet article il critique aussi fortement l’approche initiale de Canonical concernant son fork et appropriation de libhybris. Ils sont depuis rentrés dans le rang, mais l’origine même de Mir n’a plus aucun fondement maintenant qu’il est possible de tout faire avec Wayland+libhybris+android en libre.
[^] # Re: Date du SoC Intel Valley View : fin 2013
Posté par Aissen . En réponse à la dépêche État des pilotes graphiques libres pour SoC. Évalué à 2. Dernière modification le 07 mai 2013 à 15:06.
Haha, c’est assez comique, moi qui tablait sur une sortie fin 2012 (bon en même temps ma source c’était phoronix, ça m’apprendra):
https://linuxfr.org/users/aissen/journaux/attention-aux-derniers-intel-atom
Sinon, la grosse question c’est est-ce que Silvermont d’Intel va rester comme sur Saltwell sur du GPU PowerVR d’Imagination (qui risque d’être boudé par les fabricants de processeur depuis qu’ils ont racheté de MIPS Technologies), ou est-ce qu’ils vont passer sur une solution maison à la ValleyView:
http://www.realworldtech.com/silvermont/8/
http://www.extremetech.com/computing/155082-intels-silvermont-revealed-after-a-five-year-snooze-intel-is-finally-ready-to-crush-arm
Dans le second cas ça serait révolutionnaire, car on aurait dans des smartphones et tablettes une stack graphique 100% libre. À noter aussi, la frénésie d’embauche de développeurs graphique Linux d’Intel n’est peut-être pas un hasard…
[^] # Re: Sombre futur
Posté par Aissen . En réponse à la dépêche Des infos sur les Google Glass. Évalué à 4.
Il me semble qu’il s’agit de commandes vocales, et non de reconnaissance vocale (sauf pour la recherche). Ces commandes sont assez basiques, et volontairement restreintes, et seraient donc analysées hors ligne.
[^] # Re: Encore du chemin
Posté par Aissen . En réponse au journal Nous prépare t on aux DRM généralisés pour les imprimantes 3D?. Évalué à 7.
Ah ? Les imprimantes industrielles de chez shapeways supportent l’acier inoxydable:
http://www.shapeways.com/materials/steel
[^] # Re: RAID dans BRTFS
Posté par Aissen . En réponse à la dépêche Sortie du noyau Linux 3.9. Évalué à 3.
Non, bien évidemment. La première chose à faire pour bidouiller tranquillement un système android étant d’installer son binaire busybox (comme décrit dans le lien plus haut).
[^] # Re: RAID dans BRTFS
Posté par Aissen . En réponse à la dépêche Sortie du noyau Linux 3.9. Évalué à 3.
Non, Android n’utilise pas busybox, c’est GPL, ça pourrait être gênant. Ils utilisent une solution maison:
http://elinux.org/Android_Tools#busybox
https://github.com/android/platform_system_core/tree/master/toolbox
Cf http://www.elinux.org/Busybox_replacement_project pour voir que ça dérange les industriels le copyleft et les procès intentés par des auteurs de busybox.
[^] # Re: Liste des matériels supportés
Posté par Aissen . En réponse à la dépêche Sortie du noyau Linux 3.9. Évalué à 3.
En effet, depuis que Qualcomm a racheté Atheros, tout fout le camp; ils avaient commencé à proposer ça upstream, mais c’était trop dégueu:
http://lkml.indiana.edu/hypermail/linux/kernel/1208.3/02602.html
J’ai l’impression qu’ils ont abandonné depuis… Il y a un workgroup à la Linux Foundation:
http://www.linuxfoundation.org/collaborate/workgroups/networking/alx
Mais ça reste un driver out-of-tree…
# Ag
Posté par Aissen . En réponse à la dépêche ack 2.0. Évalué à 9.
Il y a également ag, qui est une ré-implémentation en C de ack:
https://github.com/ggreer/the_silver_searcher
C’est plus rapide que ack dans le cas généra, et aussi rapide que git grep dans les dossiers gérés par git par exemple.
# Pression sociale
Posté par Aissen . En réponse au journal Arrêter l'alcool, premier bilan. Évalué à 5.
Très intéressant retour !
Pour voir un autre avis de quelqu’un qui ne boit pas, et qui ressent cette pression sociale, voir ici:
http://www.pingoo.com/2013/02/22/les-buveurs-dalcool-sont-des-gros-cons/ (attention, langage non édulcoré).
[^] # Re: ack
Posté par Aissen . En réponse à la dépêche Coloriser des flux de texte avec colout. Évalué à 2.
Il te faut dans ce cas ag (better than ack):
https://github.com/ggreer/the_silver_searcher
En gros une réimplémentation en C de ack. Très rapide.
[^] # Re: Bonne idée
Posté par Aissen . En réponse à la dépêche Libre en fête 2013 à Rennes : présentation et formation autour des EFL. Évalué à 2.
Il l’est depuis un moment, mais coincé dans experimental, car beaucoup de monde est occupé par le freeze:
http://packages.qa.debian.org/e/e17.html
[^] # Re: fin du mystère
Posté par Aissen . En réponse au journal Attaque DDoS contre Spamhaus. Évalué à 3.
Pas aussi simple… voir http://www.lesinrocks.com/2013/03/29/actualite/cyberattaque-nucleaire-non-internet-ne-va-pas-seffondrer-11379197/ , qui eux ont prit la peine d’interroger des experts.
[^] # Re: GPL et BSD sont dans un bateau...
Posté par Aissen . En réponse au journal Mon évolution vis à vis du copyleft. Évalué à 5.
C’est intéressant, mais je pense que la BSD est suffisante pour utiliser le même principe de game theory, à partir du moment où le projet évolue suffisamment rapidement.
L’intérêt est alors non pas de garantir que les autres pourront utiliser sans reverser (ils le peuvent), mais de garantir qu’on ne prendra pas assez de retard, et que les coûts de maintenance ne vont pas exploser. Ainsi, si un acteur décide de se la jouer solo, il sera pénalisé par rapport aux autres acteurs qui eux continuent d’avancer, et ses couts de maintenance vont exploser s’il décide de garder sa partie proprio secrète, sans la proposer à upstream. Ça ne marche que pour les projets dynamiques, pour lesquels le code est une cible mouvante permanente. Il faut aussi qu’il y aient suffisamment de gros acteurs (> 3) qui contribuent pour que ça marche.
[^] # Re: Système de fichiers pour Flash
Posté par Aissen . En réponse à la dépêche Sortie du noyau Linux 3.8. Évalué à 6.
Ce n’est pas aussi simple car l’objectif de Samsung est de mettre ça dans des appareils mobiles qui utilisent souvent une eMMC. Certaines des ces eMMC sont faites par Samsung, et dans tous les cas, l’ensemble des propriétés des FTL de ces cartes sont connues par Samsung… C’est donc un avantage, car les deux (le FS et le FTL de la carte) s’emboîtent alors très bien. Il y a très peu d’amplification d’écriture par exemple.
Là où le bas blesse c’est lorsqu’on veut utiliser F2FS sur une carte SD dont on ne connaît pas les propriétés (les tailles de blocs), et ben ça n’est plus du tout efficace. Et rien n’est prévu dans le filesystem pour "découvrir" les paramètres de la SD sous-jacente, il faut le tuner selon les propriété de la carte, ce qui n’est pas un problème pour Samsung, mais un peu plus pour un bidouilleur dans son coin.
J’ai reprit une partie de ce qui est expliqué ici: http://lwn.net/Articles/518988/
[^] # Re: Une seule main
Posté par Aissen . En réponse au journal De la conception d'une disposition BÉPO pour Android…. Évalué à 4.
Ce qui est vraiment très puissant dans Android 4.2 c’est de taper avec des gestes, à la Swype. Ça marche très bien, voire mieux que l’original. Idéal pour une seule main. Et quand on veut taper "normalement" (lentement) c’est possible.
[^] # Re: complétion automatique
Posté par Aissen . En réponse au journal De la conception d'une disposition BÉPO pour Android…. Évalué à 2.
C’est exact, le moteur et tout est libre (et très puissant depuis 4.2). Mais pas les données. Il n’y a pas de dico de complétion/correction dans AOSP à ma connaissance.
# Bépo sur Android
Posté par Aissen . En réponse au journal De la conception d'une disposition BÉPO pour Android…. Évalué à 3.
AnySoftKeyboard le fait déjà:
http://bepo.fr/wiki/Android_:_installation
Mais je suis d’accord, la meilleure solution est de demander à ce qu’il soit intégré dans AOSP. Je ne suis pas au courant d’une telle initiative.
Il faudrait également rajouter une keymap dans Android pour les claviers externes, pour le cas ou l’on branchez un clavier physique via USB par exemple.
[^] # Re: Utilité ?
Posté par Aissen . En réponse à la dépêche Méthode et outils pour la veille technologique. Évalué à 5.
Si tout cela te semble évident (à moi aussi), c’est peut-être parce que la cible (LinuxFr) n’est pas la bonne. Mais ce n’est pas une raison pour ne pas résumer toutes ces techniques fondamentales dans un court article qu’on sera bien content d’envoyer aux béotiens.
Je salue l’initiative.
# Steam Beta ouvert
Posté par Aissen . En réponse au journal Le Bundle revient, humblement indépendant. Évalué à 7.
Tant qu’on est à parler de jeux proprios, Steam Beta sort de la phase de test privé:
http://store.steampowered.com/news/9638/
Non pas que c’était difficile de l’utiliser avant, mais au moins maintenant vous pouvez le faire sans scrupules.
# Device tree
Posté par Aissen . En réponse à la dépêche Sortie du noyau Linux 3.7. Évalué à 9.
Une simplification un peu rapide. Les device tree ont été abordé précédemment:
https://linuxfr.org/news/sortie-du-noyau-linux%C2%A02639#toc_34
https://linuxfr.org/news/le-noyau-linux-est-disponible-en-version%C2%A030#toc_25
En gros, le fichier de description est bien un fichier texte(platforme.dts), mais il est compilé en une structure de donnée binaire (platforme.dtb), et c’est ce qui est passé par le bootloader. Pour le cas où le bootloader est trop vieux et ne supporte pas le passage de dtb, celle-ci peut-être concaténée à l’image noyau, et celui-ci la charge de lui même. Mais on perd l’intérêt d’avoir une seule image pour plusieurs plateformes.
[^] # Re: ArchLinux
Posté par Aissen . En réponse au journal Non, systemd n'est vraiment pas parfait ! (ni prêt). Évalué à 7.
Normal:
http://lists.freedesktop.org/archives/systemd-devel/2011-June/002624.html
C’est pas si mal pensé quand tu creuses… Par contre un:
pourrait tuer le screen; mais pas sûr qu’il fasse un kill -9.
[^] # Re: Pétard mouillé
Posté par Aissen . En réponse à la dépêche Broadcom libère la pile graphique du Raspberry Pi. Évalué à 5.
Pour certains oui. Ce n’est en tous cas pas le cas de tous les développeurs impliqués dans la pile graphique libre.
Ce GPU est particulier, et différent de tous les autres dans la mesure où sont "firmware" tourne sur un processeur qui a plus de charge que ce qui se fait habituellement. Habituellement, le firmware s’occupe de taches annexes comme la gestion de l’énergie, ou décharger le CPU de quelques opérations lourdes. Ici, l’intégralité du driver est sur un autre processeur, dans ce qu’on appelle "firmware". Firmware qui contient l’implémentation OpenGLES ou encore le compilateur de shaders (!). Ce dernier est l’un des composant les plus secrets des GPU.
Et il m’est d’avis que ce n’est pas dû au hasard. Broadcom est un des derniers entrants dans le domaine des SoC, aussi ça ne m’étonnerai pas qu’au moment du design du GPU, ils aient fait ce choix en pensant aux drivers "libres" sous Linux. Ou alors ils voulaient vraiment que le CPU fasse un minimum de choses pour minimiser la consommation, mais j’en doute fort.
Donc sans accès aux basses couches du GPU, ce driver est fort peu utile vu qu’on ne peut écrire de driver Mesa. Ça veut dire qu’on est tributaire du bon vouloir de Broadcom pour corriger les bugs de l’implémentation, améliorer les performances, rajouter des extensions OpenGL(ES), ou s’assurer que la mémoire mappée par le GPU ne vas écraser notre bon vieux sudo (raisons de sécurité).