Bonnefille Guilhem a écrit 644 commentaires

Si Neuf intègre les fonctionnalités de Fon dans sa Box, c'est qu'il reconnait officiellement la possibilité de partager sa connexion avec des inconnus.

Hélas, j'imagine que la responsabilité pénale reste inchangée : c'est le propriétaire de la ligne qui reste responsable de ce qui est fait de sa connexion.


Sinon, vous savez si ça a donné des idées à Free ?


Re-sinon, comment qu'on fait pour trouver des foneros prêts à parainer un illustre inconnu ?

Pour ton install, je t'invite à regarder l'option "--prefix" du script configure. Cette option est présente sur tous les logiciels utilisant autoconf. Elle permet de préciser où installer le logiciel (/usr/ par défaut).

Personnellement, j'ai l'habitude de faire un
./configure --prefix=$HOME/tools
pour les logiciels que je ne veux pas installer en tant que root.

Pour viking, actuellement cela n'apporte rien, l'exécutable étant autonome. Mais cela est particulièrement utile pour des logiciels déployant un peu plus qu'un simple exécutable (des lib., de la doc, des modules...).


Pour ton souhait pour viking, je t'invite à le formuler sur la liste. Cela dynamisera toute l'équipe. Et si tu as des compétences techniques, viens bricoler le code avec nous, toute proposition de patch est la bienvenue. Tu peux aussi décrire ton idée sur le Wiki, il est ouvert à tous (après un enregistrement qui est libre).

Merci pour le test.

Concernant la présence de l'exécutable sous src/, c'est tout à fait normal. L'exécutable est produit dans l'arborescence des sources, jusqu'à exécution de la commande "make install" qui va se charger de déployer les fichiers où ils doivent être sur le système.

Je suis vraiment désolé pour ces coquilles. En fait, j'ai fait un copier-coller d'un article écrit sur mon blog. Et je n'ai pas pris le temps de relire, même rapidement.

Honte à moi.

Bonne question. Si cela vous intéresse, il est peut-être plus intéressant d'aller rencontrer les contributeur francophones sur la liste mailto:talk-fr@openstreetmap.org

Je vais quand même tenter une réponse (forcément incomplète).
Je connais au moins deux possibilités :
- Yahoo permet l'utilisation de ses photos aériennes pour tracer sur OpenStreetMap, ce qui est alors faisable avec l'applet d'édition ou avec le programme JOSM (plus de détails sur le wiki http://wiki.openstreetmap.org/).

- y'a des gens qui ont des GPS mais pas le temps de traiter l'information. Ils se chargent donc juste d'uploader leurs traces sur le serveur, chargent à d'autre d'utiliser ces traces pour dessiner la carte.

Sinon, pour une présentation plus complète du projet, vous pouvez toujours aller jeter un coup d'oeil à cet autre journal : http://linuxfr.org/~wawet76/21610.html

Moi, j'utilise Git. La raison initiale est que c'est le premier que j'ai découvert quand je suis rentré dans le monde de la gestion de version décentralisée.

Maintenant, je me sers exclusivement de Git comme "frontend" à mes dépots SVN. Du coup, au jour le jour je me sers de :
- git-svn pour synchroniser mes dépots Git et mes dépots SVN
- git-gui pour fabriquer les commit
- gitk pour me ballader dans l'historique

Grâce à git-gui et gitk je ne tape JAMAIS de commande Git. Alors le fait que Git propose plus de 150 commandes... ça ne me gène pas outre mesure au jour le jour.


Sinon, j'essaye de bosser sur giggle, une interface graphique à Git en Gtk+ : http://developer.imendio.com/projects/giggle

Et à part un comparatif "objectif" et froid, vous utilisez quelle solution de virtualisation vous ?

Je suis tout à fait d'accord.

Personnellement, je regrette la disparition de cogito. Aujourd'hui, Git offre (bien) plus d'une centaine de sous-commande, mélangeant les commandes quotidiennes, des commandes occasionnelles ou dédiée à une façon de faire (git-bissect par exemple), des commandes de niveau implémentation ("plumbing" comme ils disent).

Perso, je ne me sert plus que de git-gui, car sinon je sais jamais quelle (série de) commande effectuer pour faire des tâches quasi rudimentaire.


Espérons qu'il finiront par trouver une solution à ce problème de "mélange".

C'était pas SILC le futur de l'IRC ?

http://www.silcnet.org/

Grace au lien précédent, j'ai trouvé Lives : http://lives.sourceforge.net/

Après un test rapide, il répond à mes attentes. Par contre, ma machine semble peiner (Athlon 1800+). Mais j'imagine que c'est "normal" : l'édition vidéo requiert beaucoup de ressources.

En fouillant, j'ai trouvé un article : http://www.paulla.asso.fr/spip.php?article111

Le "Desktop linux" aurait vraiment besoin d'un projet fédérateur de base de données PIM. Sur Freedesktop.org on a Galago qui tente de rattrapper le coup pour les contacts en piochant dans les applis compatibles. On a Opensync pour la synchro. C'est tout...

Je ne suis pas vraiment au fait des projets de FreeDesktop.org. Par contre, j'avais découvert le projet Portland : http://portland.freedesktop.org/wiki/TaskAddressbook
Est-il implémenté quelque part ?

C'est bien ce qu'il me semblait : y'a plus d'équivalent gnome-pim. J'allais passer à gpe-contacts et consort, mais pimlico semble bien. Je vais essayer.

Merci du tuyau.

En fait, je fais comme ça aussi. Mais je trouve que ce n'est pas très "sexy" comme solution. Et puis je voudrais abandonner sylpheed sur mon desktop pour Thunderbird.

Et vendre mon palm IIIxe (quelqu'un en veux, c'est pas cher :-))

En parlant de contacts et de carnet d'adresse, c'est quoi le carnet d'adresses pour un environnement Gnome aujourd'hui ?

A une époque il y avait gnome-pim, mais c'est mort il me semble.
Y'a bien Evolution qui fournit tout un basard, mais j'aime pas Evolution car c'est une application intégrant plein de fonctions et je préfère les petites applications dédiées.

De plus, je me dit qu'en 2007, il doit bien y avoir une super appli/framework Gnome qui gère les contacts et fournit des services aux autres applis du bureau. Par exemple, j'imagine que pidgin et Ekiga peuvent/pourraient aller piocher leurs carnet d'adresse dans un truc central, plutôt que chacun son carnet d'adresse. Ce carnet central serait aussi utilisé par Claws-mail ou Thunderbird pour trouver les adresses e-mail.

Merci d'avance pour toutes vos infos.

Tiens, c'est marrant, hier je découvrais justement Vuze (j'avoue ne pas l'avoir testé) qui semble proposer le même genre de fonctionnalité mais exclusivement orienté P2P.
http://www.vuze.com/


Le P2P vidéo légal serait-il en train de chercher à s'afficher pour faire taire les rumeurs P2P=pirates.

Si ce n'est déjà fait, il peut être intéressant de diffuser certaines de ces informations via le projet Gutenberg.

http://www.gutenberg.org/browse/languages/fr

SVN est plutôt bien intégré, même si je n'aime pas trop l'affichage de la diff et que je ne peux pas sélectionner certains fichiers pour le commit (c'est soit le fichier courant, soit tout le projet … peut pas envoyer un .h et un .c ensemble :-| ).

Ben si on peut pas commiter un .c et son .h sans emporter le reste du projet, alors je dirais que SVN est plutôt mal intégré. En effet, c'est un des apports majeurs de SVN par rapport à CVS la notion de changeset.

Perso, une des fonctions que j'attend d'un IDE, c'est de m'aider dans la gestion de version. Je vois, avec plaisir, que SVN est maintenant intégré à anjuta, je vais donc le tester à la moindre occasion.

Par contre, depuis quelques mois, j'ai quitté le monde CVS/Subversion pour me tourner vers un monde nouveau (pour moi) : celui des gestion de version décentralisée (Git, Mercurial et consort).
Savez-vous si des gens travaillent à intégrer ces outils dans Anjuta ?

Sujet fort intéressant que celui auquel s'attaque SCENARI.

Une question toutefois : la notion de "compilation de texte" (que vous nommez "chaîne éditoriale") est bien vieille (LaTeX, DocBook...), or je ne vois pas de comparatif de SCENARI avec ces techniques (avantages/inconvénients), ais-je mal cherché ?

De loin, sans avoir testé, j'ai l'impression qu'il faut tout se faire avec SCENARI :
- la structure du document (équivalent de la DTD DocBook)
- les rendus
- ...

Forcément, cela a un avantage majeur si on a un besoin bien spécifique (moins complexe ou plus précis que DocBook) qui reviens très très souvent. Auquel cas il est rentable d'investir dans la définition d'une structure.

Mais quid des gugusses comme moi qui ont des besoins mouvants, pour lesquels le large spectre de DocBook convient, même s'il n'est jamais exploité en totatilité dans chacun de mes documents. Dans mon cas, le seul problème, c'est que les technos autour de DocBook sont plutôt "poilues". Dur dur de se lancer dans la définition d'un rendu maison ou pour le client. Avez-vous prévu de transposer DocBook (ou une version (pas trop) allégée) de DocBook dans SCENARI ?

Dans ce que tu décris je vois deux problèmes à distinguer :
- la multiplicité des systèmes de gestion de version
- la difficulté à contribuer

Dans le second cas, je pense que c'est inévitable. Quoi qu'on veuille en penser, la programmation n'est pas "triviale" (les langages, les bibliotèques, les outils support...). Il y a forcément des tas de machin chose à régler avant de pouvoir générer un produit. Je ne parle même pas de la mise en place d'un envirronnement de test de ses modifs. Mais cela est inévitable. Je ne vois pas comment on peut éviter ces "inconvénients".


Concernant le premier point, les systèmes de gestion de version distribué peuvent justement aider l'utilisateur à n'avoir qu'un seul outil, qui se charge alors de communiquer avec les dépots, quelque soient leurs types (cf. mon autre post).

Par contre, c'est un peu fort de dire que les systèmes de gestion de version sont un frein au fait de contribuer du code. Au contraire, c'est grâce à eux que l'on peut travailler à plusieurs sans perdre inutilement du temps (écrasement des modifs du copain entre autre).

Je confirme l'avis de Xavier.

Dans mon idée, les DSCM sont un outil FORMIDABLE (oui je le crie) pour les bidouilleurs du dimanche, qui bricolent plein de projets et (du coup) ne feront que de rares contributions. Dans ce cas, il n'est pas vraiment utile d'avoir un accès en écriture au dépot du projet. Il est bien plus efficace de soumettre ses modifications occasionnelles par patch.

Dans cette optique, je pense que l'outil qui restera sera celui qui offre le plus de "connectivité" avec les autres systèmes. En effet, ce n'est pas très productif de devoir sans cesse apprendre un nouvel outil pour récupérer les modifs des copains et calculer ses propres patches. Ce boulot doit être fait par l'outil DSCM. C'est à lui de savoir communiquer avec les autres, pas à l'utilisateur. Ainsi, le petit contributeur du dimanche peut rester productif car il manipule toujours le même outil (celui de son choix) même s'il participe à différents projets utilisant différents types de dépots.

Dans ce domaine, Git est plutôt bien founi il me semble. J'utilise Git en frontend SVN et ça fonctionne du tonnerre. Pour Git avec CVS, j'ai l'impression que c'est un peu plus laborieux. Il faudrait que les outils évoluent pour un meilleure prise en charge. En ce qui concerne Git et les autres (Bzr, mercurial, monotone...) je ne sais pas, mais il me semble avoir vu passer des trucs sur la mailing-liste.

C'est rare de payer plus cher pour avoir quelque chose en moins...

Ca me fait un peu penser aux produits allégés. J'ai jamais vraiment compris pourquoi un produit dans lequel il y a moins de sucre est plus cher :-)

GNUstep devait être le projet initial de bureau du projet GNU

GNUstep sera le bureau du projet GNU. Je crois qu'ils ont synchroniser leur release avec celle du noyau correspondant : Hurd. :-)

PS : désolé, mais comment résister à un si bon troll

Blague à part, pour avoir tenté deux trois trucs avec GNUstep, c'est plutôt sympa comme vision du développement d'IHM.

Moi, ce qui me fait marrer, c'est que les rares extraits de vidéo sont des vidéos... de pub. Si ça se trouve, Microsoft.fr fait payer une licence au "Petit Marseillais" à chaque fois que cette présentation de Vista est diffusée.

Enorme !

Y'a pas à dire, c'est beau un esprit propre et disponible.