Note : Ce billet aborde la question sous un angle purement technique.

On peut se demander pourquoi les pilotes (libres ou non) des appareils fonctionnant sous Android (spécialement les ordiphones et tablettes) ne marchent pas avec nos distributions GNU/Linux habituelles (ou, autrement dit, pourquoi nos distributions GNU/Linux ne peuvent pas facilement tourner sur un appareil fonctionnant sous Android), alors que les deux partagent le même noyau : Linux.

Pour rappel, une distribution GNU/Linux inclut généralement a minima :

• un noyau : Linux (créé en 1991),
• des composants du projet GNU (lancé en 1984) comme glibc (pour GNU C Library – la bibliothèque C GNU créée en 1987), coreutils (pour GNU Core Utilities – les outils de base GNU), Bash (pour Bourne-Again shell – le shell GNU).

S'il s'agit d'une distribution pour poste de travail (et pas seulement pour serveur), celle-ci inclura en outre :

• un serveur d'affichage : X.Org, dérivé en 2004 de XFree86 (lui-même créé en 1991) et qui devrait céder prochainement sa place au récent Wayland (ou à Mir, dans le cas d'Ubuntu),
• un environnement logiciel comme GNOME (lancé 1997, basé sur la boite à outils graphiques GTK+), KDE (lancé en 1996, basé sur la boite à outils graphiques Qt) ou Xfce (lancé en 1996 et basé sur GTK+).

Android, sorti fin 2007, a pour seul point commun Linux, le noyau du système d'exploitation (rappelons à ce sujet que, depuis octobre 2011, les projets Android et Linux collaborent pour minimiser les différences entre la version utilisée par le premier et celle publiée par le second).

Android utilise en effet son propre environnement d'exécution (Dalvik), sa propre boite à outils graphiques, son propre serveur d'affichage (SurfaceFlinger) mais surtout sa propre bibliothèque C : Bionic libc.

Ces choix correspondent, pour la plupart, au fait que les besoins pour un ordiphone ou une tablette sont plus limités que pour un PC, tout comme les ressources matérielles (processeur, mémoire). Les solutions logicielles retenues ont donc généralement des fonctionnalités plus limitées mais une empreinte mémoire plus faible.

Les conséquences de ces choix sont que les applications conçues pour Android ne fonctionnent pas directement sur une distribution GNU/Linux mais aussi, de manière plus embêtante – et peut-être plus étonnante, que les pilotes conçus pour Android sont inutilisables par une distribution GNU/Linux.

Ces pilotes sont en effet conçus pour la bibliothèque C d'Android (Bionic libc) qui n'est pas compatible avec la bibliothèque C du projet GNU (glibc).

À noter que FirefoxOS, dont la sortie est prévue pour cet été, repose également sur un noyau Linux et la bibliothèque Bionic libc de sorte qu'il pourra utiliser directement les pilotes conçus pour Android et être ainsi, dès sa sortie, compatible avec un grande variété d'appareils.

Inversement, nos distributions GNU/Linux sont compatibles avec un nombre beaucoup plus restreint d'appareils mobiles car les fabricants ne se donnent pas la peine de réaliser des pilotes pour celles-ci.

Face à cette situation, deux solutions sont possibles : développer des pilotes (libres), notamment par rétro-ingénierie (c'est, par exemple, ce qui est en train d'être réalisé pour les GPU embarqués dans les ordiphones et tablettes) ou s'arranger pour pouvoir utiliser les pilotes (libres ou non) conçus pour Android (via la bibliothèque libre Libhybris conçue initialement pour le projet Mer – plus ici, ici et là).

Notons pour finir que, si FirefoxOS fournit également son propre environnement d'exécution (Gecko), cela ne fait pas obstacle à l'utilisation des logiciels conçus pour FirefoxOS sur nos distributions GNU/Linux ou n'importe quel autre système puisque cet environnement met en œuvre les technologies Web (HTML, CSS et JavaScript) que n'importe quel navigateur peut exécuter.

Lire aussi : À quand les smartphones et tablettes libres ? sur LinuxFr.org.

Original post of Antistress.Votez pour ce billet sur Planet Libre.

Cela fait désormais un sacré moment que j’ai publié ma revue des solutions de synchronisation. Comme souligné par un commentaire récent, un petit retour est nécessaire.

J’utilise git pour coder. J’utilise aussi git pour synchroniser mes fichiers grâce à mon serveur auto-hébergé. Git, c’est bon, il faut en manger matin, midi et soir.
L’idée de dvcs-autosync était bonne, mais il y avait quelques bugs génants et je ne suis pas allé voir les forks. Alors, je pousse mes commits à la main. Ce n’est pas si fastidieux. A part ce point, j’ai cependant un problème. L’un de mes dépôts est dédié à synchroniser des pdf, beaucoup de pdf, environ 500, ce qui représente plusieurs Go. Ajouter/synchroniser de nouveaux fichiers ne pose pas de problèmes, mais si je devais synchroniser à un nouvel endroit, ce serait… interminable.

Il existe un projet kickstarter que je trouve génial. Je ne comprend pas pourquoi peu de gens en parle d’ailleurs. Un joli contre-exemple à ce qui est dit dans cet article de linuxfr. Grâce à l’argent des donateur, l’auteur travaille sur le projet depuis plus de 200 jours et pour les petits tests que j’ai mené, je trouve que le travail est excellent. Si vous vous demandez pourquoi sparkleshare, dvcs-autosync ou sharebox ne conviennent pas, je vous laisse lire son argumentation. Ca fait plusieurs mois que je surveille ce projet, et j’ai décidé de m’y mettre sérieusement. D’où le présent billet.

Quel est le principe de git annex pour gérer les gros fichiers ? Très simple. Plutôt que de synchroniser le fichier lui-même, on synchroniser un lien symbolique pointant vers le fichier. Ainsi, lorsqu’on "pull" le dépôt, on récupère l’arborescence des fichiers qui sont ces liens. Ceci permet de les réorganiser par exemple, sans avoir à télécharger les fichiers. C’est un gain impressionnant. Si on veut lire le fichier, il suffit de télécharger ce fichier spécifiquement. Il peut d’ailleurs être retiré par la suite une fois que les modifications ont été poussée. Ainsi, on gagne de l’espace disque.

Voici en quelque ligne, un usage de base :
git init # crée le dépôt
git annex init "my laptop" # crée une instance annex
git annex add big_file.dat # ajoute un fichier à annex
git ci -a # commit

Maintenant, on clone le dépôt que nous venons de créer :
git clone …
# là, les fichiers ne sont pas lisibles
cat big_file.dat
# mais on peut les télécharger
git annex get big_file.dat
# et les lire !
cat big_file.dat
# et on peut supprimer le contenu en gardant le lien symbolique
git annex drop big_file.dat

Git annex est donc conçu pour des gros fichiers, de type photos, musiques, vidéos, données… et il peut être utilisé pour

• Synchroniser deux machines.
• Partager avec des amis. (jabber inside)
• ou archiver.

Le développeur est Joey Heiss, j’ai déjà parlé ici de ces logiciels (github-backup et ikiwiki).

Original post of François.Votez pour ce billet sur Planet Libre.

Une présentation Webinar Zabbix en français est organisée pour le jeudi 6 juin 2013. Il s’agit de la première présentation française officielle par WebConférence (Webex) de la solution de supervision Zabbix. Cette présentation se déroulera à 16h (heure française).

La présentation abordera différents points techniques tels que : l’architecture Zabbix et ses options, la logique de configuration, les fonctions principales, les différents composants, les domaines d’application, le potentiel d’évolutivité de la solution, ses performances et aussi les services délivrés.

Si vous souhaitez y assister il suffit juste de s’y inscrire sur le site Zabbix :

Accéder à la page d’inscription

Soyez nombreux

Original post of Monitoring-FR.Votez pour ce billet sur Planet Libre.

Lorsque l’on a un processus qui plante, et qu’on ne peut/doit pas le relancer malgré tout, il est possible de tracer en dynamique ses appels via les bons utilitaires.

Pour Linux, c’est strace qui va faire le boulot. Lancé tel quel juste avant le run d’un programme, il décrit en console les appels, ce uqi fait qu’on est souvent amené à le rediriger. Jusque là, tout va bien. Et bien pour le faire tourner sur un processus déjà running, c’est juste une histoire d’option. Un petit test sur un processus bénin :

kx@lab:~$ ps faux | grep clement
kximei 2492 18.5 9.3 1099016 282656 pts/0 SLl 10:03 38:50 | \\_ clementine
kximei 2496 0.0 0.1 43304 4444 pts/0 S 10:03 0:00 | \\_ /usr/bin/clementine-tagreader /tmp/clementine_527453569
kximei 4802 0.0 0.0 9616 908 pts/1 S+ 13:32 0:00 \\_ grep clement

kx@lab:~$ strace -f -o clementine.straced -p 2492
Process 2492 attached with 17 threads - interrupt to quit
Process 4804 attached (waiting for parent)
Process 4804 resumed (parent 2492 ready)
Process 4805 attached (waiting for parent)
Process 4805 resumed (parent 2492 ready)
Process 4806 attached
Process 4807 attached
Process 4808 attached (waiting for parent)
Process 4808 resumed (parent 2492 ready)
Process 4809 attached (waiting for parent)
Process 4809 resumed (parent 2492 ready)
Process 4808 detached
Process 4809 detached[...]

Toutes les traces ont été stockées sur ./clementine.straced, et ça donne ça, enfin snippé bien sûr :

kx@lab:~$ less clementine.straced
4776 restart_syscall(<... resuming interrupted call ...> 
4407 futex(0x534be04, FUTEX_WAIT_PRIVATE, 8067, NULL 
3236 ppoll([{fd=70, events=POLLIN|POLLPRI|POLLERR|POLLHUP|POLLNVAL}], 1, {0, 22601540}, NULL, 8 
2517 futex(0x4097774, FUTEX_WAIT_PRIVATE, 9883, NULL 
2510 restart_syscall(<... resuming interrupted call ...> 
2507 restart_syscall(<... resuming interrupted call ...> 
2505 restart_syscall(<... resuming interrupted call ...> 
2504 restart_syscall(<... resuming interrupted call ...> 
2503 restart_syscall(<... resuming interrupted call ...> 
2502 restart_syscall(<... resuming interrupted call ...> 
2501 restart_syscall(<... resuming interrupted call ...> 
2499 restart_syscall(<... resuming interrupted call ...> 
2498 restart_syscall(<... resuming interrupted call ...> 
2495 select(6, [5], NULL, NULL, NULL 
2494 restart_syscall(<... resuming interrupted call ...> 
2492 restart_syscall(<... resuming interrupted call ...>) = 0
2492 read(7, 0x2f596f4, 4096) = -1 EAGAIN (Resource temporarily unavailable)
4730 futex(0x46d0dd4, FUTEX_WAIT_PRIVATE, 8061, NULL 
2492 ioctl(73, 0x4122, 0x3) = 0[...]

Sous Solaris, c’est truss qui fait le boulot, et c’est toujours la même rengaine : truss snoop crache en console, alors que truss -faied -o 2581.strussed -p 2581 attrape le process de pid 2581 et récupère ses appels sous ./2581.strussed.

Ca peut toujours servir :)

[Photo par Jeroen Bennink]

Original post of K-Tux.Votez pour ce billet sur Planet Libre.

Plop les bovins, Greg Kroah-Hartman et Linus Torvalds viennent d’annoncer la troisième mise à jour  pour la branche 3.9.x. du noyau Linux 3.9.3, qui embarque quelques corrections de bugs et surtout, l’introduction de nouvelles portions de code visant à améliorer l’optimisation et le support du kernel.

Le noyau Linux 3.9.3 introduit plusieurs corrections spécialement dédiées au soutien des processeurs ARM Samsung Exynos, OMAP 5 et aux soutient des nouvelles plateformes ARM V6/V7. Nous trouvons également différentes corrections de bugs concernant le soutien des nouveaux processeurs Intel et et des correctifs censés régler divers problèmes affectant cpufreq. D’autres améliorations incluent un meilleur support pour les pilotes libres AMD et nous relèverons l’ajout de quelques lignes de code, écrites en collaboration avec AMD et valve.

On notera enfin, diverses corrections concernant entre-autres des problèmes rencontrés avec les cartes sans fil Atheros « ath9k » (affectant l’activation du mode économie) et de nouvelles mises à jour pour ALSA, fixant certains problèmes audio (via HDMI).

Si ça vous intéresse, vous pouvez consulter le changelog pour cette version 3.9.3 du noyau Linux en vous rendant sur cette page. Si vous avez envie de tester le bel animal, nous allons voir tout de suite comment procéder.

Avertissement!

Avant de vous lancer sachez que cette manipulation n’est pas sans risques. Si vous n’êtes pas un familier des environnements GNU/Linux, que vous ne savez pas récupérer un système endommagé ou devenu instable, passez votre chemin… Dans tous les cas pensez à effectuer une sauvegarde de votre système avant de commencer. La team.

Pour installer le noyau Linux 3.9.3 vous pouvez au choix télécharger les paquets sur cette page, pour une installation manuelle. Ou passer par le script upubuntu.com, en entrant ces quelques lignes de commande dans votre terminal.

NB  : Vous pouvez jeter œil sur le script avant, en le téléchargeant à l’aide de cette ligne de commande :

wget https://dl.dropboxusercontent.com/u/47950494/upubuntu/kernel-3.9.3 -O kernel-3.9.3

Installer le noyau Linux 3.9.3 sur Ubuntu et Linux Mint :

cd /tmp
wget https://dl.dropboxusercontent.com/u/47950494/upubuntu/kernel-3.9.3 -O kernel-3.9.3
chmod +x kernel-3.9.3
sudo sh kernel-3.9.3
sudo reboot

Désinstaller le noyau Linux 3.9.3 :

sudo apt-get purge linux-image-3.9.3*

Amusez-vous bien.

Moo!

source

Original post of Noireaude.Votez pour ce billet sur Planet Libre.