kaliko a écrit 60 commentaires

Je surveille git-annex depuis quelque temps, cette solution me semble prometteuse.

Ok, ce n'est pas la même génération, mais tout de même, « recenser des développeurs français qui ont marqué le paysage mondial » et faire l'impasse sur le concepteur du datagramme et du réseau à commutation de paquet, ben cela est surprenant.

Pour préciser suite au commentaire de plietar et azmeuk:

Je parle bien-sur d'échanges de commit entre différentes "forge", applications web au dessus de git.

Git gérant déjà cela à la "unix" via le formatage d'un patch à piper dans un mail :)

J'avoue ne pas avoir beaucoup cherché (j'héberge moi-même mes dépôts de source), mais que ce soit sur gitorious ou github, je n'ai jamais vu la possibilité de faire des "pull-request"® entre dépôts sur des serveurs différents.

Par exemple, pourquoi ne pourrais-je demander à un projet sur gitorious.org de tirer des modifications que j'ai publiées sur mon dépôt git://git.kaliko.me/projet.git ?

Il me semble que c'est une des fonctionnalités fondamentale de git àmha (le D de DVCS). Je comprends l'absence de cette fonctionnalité chez github dont l’intérêt est
plutôt d'agréger autour de sa plate-forme le plus de projets (via les "fork"®), qu'en est il de gitlab sur cet aspect social ? Différente instances de gitlab peuvent elles communiquer entre elles ? avec d'autres dépôt git ?

Pour moi c'est plutôt à ça que ça ressemble une mise à jour avec aptitude:

C'est plutôt lisible àmha.

apt et aptitude sont des gestionnaires de paquets au-dessus de dpkg.

La question est plutôt de savoir où se positionne apti. Je trouve curieux d'utiliser aptitude plutôt qu'un bibliothèque dédiée, de mémoire elles existent pour perl et python. Quant à ruby je pense que apt-listbug s'appuie sur un module dpkg. Bref il existe des interface de programmation qui me semblent plus indiquées.

Depuis quelques jours, Oracle a décidé d'interdire l'exécution des applets ne précisant pas leur nom d'application (Application-Name) dans le fichier de description MANIFEST.MF.

Un petit lien concernant la source de cette information ?

merci :)

En effet, je pratique bogofilter avec fdm depuis quelques années maintenant, très satisfaisant par rapport à spamassassin.

Un 'tite typo dans le dernier paragraphe

quand on utilise lancer des programmes (subprocess)

:)

Il existe aussi git-annex qui n'est pas tout à fait la même chose mais dont les fonctionnalités offrent une solution alternative à "foofle keep".

Mais bon, en allant plus loin encore, un simple éditeur de texte et un bon client git rendent déjà "foofle keep" obsolète pour le nerd de base. Bon ok, keep ne s'adresse pas forcement à ce public…

Je n'ai pas vu d'ordre de grandeur de la consommation électrique pour cette carte.

C'est toujours un critère pertinent pour ce type de matériel dont une application typique peut être l'auto-hébergement.

À noter cependant:

« Bien qu'ils ne soient pas faits spécialement pour Linux, ils fonctionnent tous sur cet OS grâce à Wine (tests réalisés sur Ubuntu +Wine) » source

Un autre livre dans le même domaine, empaqueté sur debian :
http://packages.debian.org/cfi-en

Je ne trouve plus la traduction anglaise, précédemment disponible sur http://svenskefaen.no/cdne/

J'ai bien conscience de l'intérêt de mutualiser et capitaliser ce genre d'information, je développe MPD_sima qui s'appuie justement sur la base de donnée de last.fm qui est construite à partir des statistiques d'écoute.

Comme précisé dans la dépêche, l'aspect social de last.fm n'est pas du tout présent sur scrobblerserver. Le but premier était la génération d'un log d'écoute et de statistiques, pas l'aspect social de last.fm (avec entres autre la découverte de musique, l’intelligence collective etc…). Mon objectif dans un premier temps était de reprendre le contrôle de nos données. Cependant le développement du réseautage social peut s'appuyer sur une brique comme scrobblerserver. Comme tu précises dans ton commentaire, il pourrait exister une solution de fédération de scrobbler (le mien et d'autres) à l'image de ce qui existe pour le mail, le micro-blogging (status.net), la messagerie instantannée (xmpp), etc…

Ces évolutions sont bien plus conséquentes en termes de développement (définition d'un protocole entres autres), de plus elles demandent la création et la gestion d'une communauté autour du projet, ce qui est délicat à mener àmha (cf. libre.fm). Hors ce second point est critique dès qu'il s'agit de sollicité l'effet réseau.

Bref, c'est une évolution très intéressante et ambitieuse pour le projet. On peut voir cette initiative, celle de libre.fm et d'autres dont je n'ai pas connaissance comme des amorces pour créer de véritables alternatives ouvertes et décentralisées à last.fm.

En effet, c'est un problème. Il y a aussi les artistes différents qui ont le même nom "John Williams" par exemple.
C'est pour cette raison que je privilégie l'utilisation des id MusicBrainz.

Dans tous les cas, si on veut commencer à jouer avec ça médiathèque (par ex. MPD_sima ou d'autres gestionnaires de playlist dynamique), la base est d'avoir son contenu taggué le plus précisément possible. En ce qui concerne la musique je n'ai encore rien trouvé de mieux que la base de donnée de MusicBrainz pour renseigner les tags de ma musique.

https://musicbrainz.org/

Je suis tombé récemment sur un bout de code permettant de facilement colorer du texte sur la sortie standard.

https://gist.github.com/martin-ueding/4007035

print('{red}ERROR{reset} {orange}All your base are belong to us!{reset}'.format(**_c))

J'ai trouvé ça utile pour les quelques utilitaires que je développe pour la console.

En effet, pour faire tourner glances sur Debian stable il faudrait repasser sur une ancienne version de glances (<1.4), celles ci fonctionnaient avec python-statgrab.

Merci pour ton retour :)

Un paquet Debian pour cette version est en travail.
N'hésitez pas à l'essayer et faire des retours.
La version 1.4.2 est déjà dans les dépôts officiels pour unstable/sid.

k.

[0] http://git.kaliko.me/?p=glances.git
[1] http://kaliko.me/media/glances_1.5.1-1_all.deb

En effet la réponse 1 n'est pas vraiment pertinente àmha.

Le seul point noir que je trouve actuellement à mpd est l'impossibilité de réindexer seulement une partie des média

Si je comprends bien ce que tu cherches, je crois bien que c'est possible oui.
Dans le manuel de mpc :

update  [--wait] [<path>]

   Scans for updated files in the music directory.  The optional parameter <path> (relative to the music directory) may limit the scope of  the update.

   With --wait, mpc waits until MPD has finished the update.

à l'heure actuelle, MPD est surtout défavorisé par les clients disponibles.

C'est vrai que le choix n'est pas forcement énorme, il y a cependant de très bon client.
GMPC est le seul qu'il m'arrive d'utiliser et je le trouve vraiment bien fichu même s'il ne convient pas à mon utilisation courante.

Bon, après c'est vrai que personnellement ce qui m'attire sur MPD c'est l'aspect client/serveur et j'utilise essentiellement MPD avec des clients console hors poste de bureau (ncmpc et MPD_sima). Je pense que c'est le créneau de ce genre de lecteur.

Au fait la vague idée de travailler avec les dev de XMMS2 est-elle morte?

C'est à dire ?
De qui parles tu ? Y a t'il jamais eu un réel et enthousiaste engouement pour xmms2 ?
J'avoue avoir été intéressé en tant qu'utilisateur quand xmm2 est arrivé. Mais étant déjà sur MPD je n'ai pas concrétisé ma curiosité.

Je ne vois pas le lien entre la liberté d'un logiciel et la disponibilité du service qu'il propose.

Ce qui est en jeu est la réactivité de l'équipe d'administration, une interruption de service (ou la compromission d'un hôte) ça peut arriver partout àmha.
Ensuite, je suis d'accord que la réactivité peut être fonction du modèle commercial derrière le service proposé. Mais une fois de plus, peut on comparer github et kernel.org sur ce point⋅?

Pour allier qualité de service et liberté, dans l'hypothèse ou le modèle commercial payant assure un meilleur disponibilité du service, il existe les solutions payantes de gitorious par exemple.

C'est tout de même très décevant de ne toujours pas pouvoir lire mes flux audio [0] dans firefox. J'ai mis en place une radio perso à base de MPD/HTML5 avec laquelle je diffuse un flux en vorbis audio mais seul Chrome peut lire ces flux pour le moment.
De mon point de vue c'est problématique pour partager ma radio avec les amis, mais surtout c'est une sacré frein à l'implantation de technologie libre pour la diffusion multimédia sur le web. De plus c'est un problème remonté depuis 2008…

[0] https://bugzil.la/455165

Je salue cette initiative.
En effet cela peut sembler faire doublon avec des projets comme la « freedom box », cependant la richesse est dans la diversité.

Go Beedbox, go!