En effet, lors du Linux Kernel Developers Summit 2005, les développeurs du noyau se rendirent compte qu'ils n'avaient aucun ordre de grandeur concernant le nombre d'utilisateurs testant les versions git, rc ou pre de la prochaine version stable du noyau.
Le projet Klive a donc été créé.
Il s'appuie sur des utilisateurs volontaires qui, avec un petit logiciel, informent la communauté et les développeurs du noyau en place sur leur machine.
Klive n'a pas besoin d'être compilé ni d'être exécuté avec les permissions du superutilisateur. Klive est un projet sous licence GPL.
Il se compose d'une partie client et d'une partie serveur, toutes deux disponibles.
C'est la partie cliente qui est utilisée par les utilisateurs, c'est donc vers elle que se portera cet article.
Le fonctionnement de Klive est simple : le logiciel récupère les informations sur la machine hôte qu'il va envoyer sur le serveur centralisant toutes les données.
Une tâche cron est utilisée pour effectuer cette action régulièrement.
Le script effectue l'installation automatiquement : il télécharge le client, le copie dans un répertoire aléatoire et intègre une nouvelle tâche dans cron pour l'éxécuter à intervalle régulier.
Depuis peu, Klive récupère également des informations sur les bus PCI et sur les modules chargés dans le noyau.
Le client et le serveur ont été réalisés avec Python et python-twisted. Ce sont les seules dépendances requises. Cependant, une version réalisé en pur Python a été écrite et est en développement. Pour plus d'informations, rendez vous sur le Wiki Klive.
Si vous voulez vous impliquer dans le projet, sachez que la mailing-list de Klive est très réactive sans avoir un débit trop important.
Aller plus loin
- Projet Klive (2 clics)
- Wiki Klive (1 clic)
- Le script d'installlation automatique (1 clic)
# Et Cron ?
Posté par KaZeKaMi (site web personnel) . Évalué à 9.
Il y a aussi Cron comme dépendance. Si on utilise par exemple fcron, le script refuse d'installer klive, ou alors (après bidouille faite de liens symboliques entre les commandes fcron et celles de cron) ne détecte pas que fcron est en fonctionnement et refuse de s'installer.
[^] # Re: Et Cron ?
Posté par TazForEver . Évalué à 3.
Sauf s'il s'agit d'un
@reboot
pour que ça démarre tout seul en utilisateur.
[^] # Re: Et Cron ?
Posté par Guillaume D. . Évalué à 1.
Calculating dependencies ...done!
[ebuild N ] net-zope/zopeinterface-3.0.1 -doc 105 kB
[ebuild N ] dev-python/pyopenssl-0.6 -tetex 275 kB
[ebuild N ] dev-python/twisted-2.1.0 +crypt +gtk -serial 1,052 kB
[ebuild N ] app-misc/klive-0.7-r2 18 kB
voila pour les dependances
A+
[^] # Re: Et Cron ?
Posté par yoho (site web personnel) . Évalué à 2.
[^] # Re: Et Cron ?
Posté par tgl . Évalué à 3.
Elle me parait bien subtile ta distinction : pour moi, si c'est requis pour un bon fonctionnement, ça devrait être une dépendance du paquet, non ?
Enfin quoi qu'il en soit, KLive marche très bien chez moi depuis des mois alors que je n'utilise que fcron. Les gens qui voudraient voir comment il est installé et lancé sous Gentoo pour faire pareil avec leur mimines, ou pour faire un paquet pour leur distrib', peuvent jeter un oeil à l'ebuild et à l'init script qui sont ici :
http://www.gentoo.org/cgi-bin/viewcvs.cgi/*checkout*/app-mis(...)
http://www.gentoo.org/cgi-bin/viewcvs.cgi/*checkout*/app-mis(...)
[^] # Re: Et Cron ?
Posté par yoho (site web personnel) . Évalué à 4.
[^] # Re: Et Cron ?
Posté par tgl . Évalué à 2.
« visiblement, ce n'en est pas une. Le post ci-dessus prouve cela »
En fait même pas, le post si dessus ne prouve pas grand chose puisqu'il liste juste les dépendances que cet utilisateurs n'avait pas d'installées (c'est une sortie de "emerge -p klive").
Mais ça ne comprends pas :
- d'éventuelles autres dépendances qu'il aurait eu de déjà installées ;
- des choses éventuellement nécéssaires aussi mais qui sous Gentoo ne sont jamais explicitées dans les dépendances parcequ'elles sont obligatoirement installées sur tous les systèmes (le genre glibc, etc.).
Le plus simple pour avoir les dépendances du paquet Gentoo, c'est encore de regarder l'ebuild, et il ne liste que Python et Twisted (les autres trucs cités au dessus étant des dépendances indirectes venant de Twisted).
Mais pour en revenir à "cron", je confirme qu'il n'y en a nul besoin (j'ai même lu les sources pour vérifier cette fois). Le paquet installe les fichiers suivants :
/usr/share/doc/klive-0.16/README.gz
/usr/share/klive/klive.tac
/etc/init.d/klive
...où le script d'init lance twisted sur le klive.tac et puis voilà, après ça tourne. Bref, faut pas hésiter à se faire une installation manuelle, ou un paquet, c'est vraiment trivial.
# Distribs?
Posté par Jean-Marc Spaggiari . Évalué à 1.
[^] # Re: Distribs?
Posté par gyom gyom . Évalué à -10.
Je précise au passage que c'est vrai pour 90% des logiciels présentés ici...
> A quand les packages pour les distrib les plus populaires?
On vous "recommande" d'installer un logiciel en tant qu'utilisateur normal, vous demandez à l'installer en root... Y'a de la mdk dans l'air...
[^] # Re: Distribs?
Posté par berti . Évalué à 10.
On ne recommande rien du tout, on dit juste qu'il n'a pas besoin d'être root. Personnelement, même si je peux installer un programme en tant qu'user, je préfère en faire un package. C'est tellement plus simple pour le virer plus tard quand on ne sait même plus dans quel répertoire on l'a installé. Et j'imagine que c'est pour la pluspart des gens la même chose, rien à voir avec mdk.
[^] # Re: Distribs?
Posté par Ludovic F (site web personnel) . Évalué à 3.
http://packages.gentoo.org/ebuilds/?klive-0.16
[^] # Re: Distribs?
Posté par Ludovic F (site web personnel) . Évalué à 2.
Klive-0.7 à été inclus dans portage le 11 Sep 2005.
Il ne s'agit donc pas d'une nouveauté.
[^] # Re: Distribs?
Posté par gyom gyom . Évalué à -10.
Tu sacrifies grandement la sécurité pour qqes avantages de rapiditié d'installation...
Je pleure d'entendre des debianeux dire des choses pareilles...
[^] # Re: Distribs?
Posté par berti . Évalué à 8.
[^] # Re: Distribs?
Posté par gyom gyom . Évalué à -9.
J'me demande d'ailleurs pourquoi tous ces gens installent des debian/unbutu, ils feraient mieux de rester sous mdk jusqu'à vraiment savoir ce qu'est linux et l'info en général, ça évitrait les trolls dui style :
YYY : "debian ça rocks !"
Moi : "pourquoi ?"
YYY : "paske" (ou des fois pour les plus au courant : "paske c'est plus sécurisé", laissez moi rire...)
(excusez je suis méchant, d'habitude c'est pas dans ma nature, mais les réponse comme celle de ce monsieur ça me dépasse...)
[^] # Re: Distribs?
Posté par yoho (site web personnel) . Évalué à 3.
[^] # Re: Distribs?
Posté par gnumdk (site web personnel) . Évalué à 3.
[^] # portnawak
Posté par Ben (site web personnel) . Évalué à 3.
Tout homme qui dirige, qui fait quelque chose, a contre lui ceux qui voudraient faire la même chose, ceux qui font précisément le contraire, et surtout la grande armée des gens d'autant plus sévères qu'ils ne font rien du tout. -- Jules Claretie
# Idée à généraliser
Posté par Valdenaire Denis (site web personnel) . Évalué à 10.
Automatiser le rapport : je fais fonctionner telle version de telle carte, avec telle moniteur, telle souris, à telle résolution, etc. vers un serveur public, ce serait pratique pour les developpeurs (retour sur ce qu'ils font) et pour les utilisateurs (est-ce qu'un gars a un jour réussi avec une telle combinaison, etc. avant d'acheter le matos) d'un certain niveau cela va de soi...
A priori tout ce qui touche au matériel aurait grand besoin de reporting.
Reste à assurer : la confiance en celui qui collecte les données (que son script fasse pas n'importe quoi) et en celui qui les envoie (qu'on pourrisse pas la base avec des données fausses.)
Enfin cela dit, je connais rien au python. En fait, j'en ai même plutôt peur. Ca etouffe ou ça empoisonne, ces bêtes-là ?
[^] # Re: Idée à généraliser
Posté par Raoul Volfoni (site web personnel) . Évalué à 4.
s/moniteur/monitrice
----tout schuss--->[]
[^] # Re: Idée à généraliser
Posté par WH (site web personnel) . Évalué à 3.
Il existe aussi un script (en Perl) chez LinuxCounter qui rapporte quelques infos à intervalles réguliers, comme le processeur utilisé, le type de kernel ou le nombre de comptes utilisateurs créés :
http://counter.li.org/scripts/
Il suffirait de les étendre un peu plus et d'augmenter leurs possibilités pour avoir des informations fiables.
# Pourquoi un répertoire aléatoire?
Posté par Sixel . Évalué à 3.
Pourquoi le copier dans un répertoire alétoire? J'ai beau chercher, je ne vois pas l'utilité...
"Il faut" (Ezekiel 18:4) "forniquer" (Corinthiens 6:9, 10) "avec des chiens" (Thessaloniciens 1:6-9) "morts" (Timothée 3:1-10).
[^] # Re: Pourquoi un répertoire aléatoire?
Posté par Paul POULAIN (site web personnel) . Évalué à 2.
Genre "ah, mon ami, tu as un noyau 2.6.6 de chez XXX... parfait, tu n'es pas protégé contre telle attaque...
bon, bien sûr, faut AUSSI que l'attaquant puisse lire le fichier sur le système. Mais 2 précautions valent mieux qu'une !
[^] # Re: Pourquoi un répertoire aléatoire?
Posté par Pooly (site web personnel) . Évalué à 4.
# C'est pour qui ?
Posté par Olivier Faurax (site web personnel) . Évalué à 7.
A ce que dit la nouvelle, ce logiciel a été créé pour savoir combien de gens testent les -git, -rc et -pre : est-ce utile de s'ajouter si on utilise un noyau stable ?
[^] # Re: C'est pour qui ?
Posté par Sylvain Rampacek (site web personnel) . Évalué à 6.
et les noyaux présents sont les stables dans ces branches, donc je pense que l'on peut !
après dire si c'est nécessaire...
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.