Articles précédents : Logiciel
- [40] Sortie de la version 2.0 de Gallery
- [30] LRS : support optimisé de LVM pour la sauvegarde système
- [63] Firefox 1.5 Beta 1 est sortie
- [208] GNOME 2.12 dans les bacs
- [15] Mambo devient Joomla
- [10] Revealicious : un outil de visualisation pour Delicious
- [8] Prométhée 4.0
- [41] Sortie de la FramaKey 1.0.1
- [11] Balazar -- Arkanae II, les sceptres reforgés version 0.2
- [14] Sortie officielle de Tiny ERP 3.0
Liens connexes
- Page d'accueil (3656 hits)
- Démo flash (2622 hits)
- DotLucene (432 hits)
- Un journal traitant du sujet (1520 hits)
Dépêche modérée par
Dépêche éditée par
Logiciel : Beagle : Un "Desktop Search" sous Linux
Posté par TImaniac (page perso, ). Modéré le 16 septembre 2005.
Beagle est un outil pour indexer et rechercher des données sur un poste local (desktop search) aux objectifs proches de ce que propose Spotlight sous MacOS X ou Google Desktop Search sous Windows.
Constitué d'un service qui tourne en tâche de fond, il observe en temps réel les modifications du système de fichier, les conversations dans Gaim ou les derniers courriels ainsi que vos chansons préférées. Un petit client graphique présent dans la barre de notification permet de retrouver instantanément un document ou un média.
![[en]](../../../images/en.png)
Page d'accueil (3656 hits)-
Démo flash (2622 hits)
-
DotLucene (432 hits)
![[fr]](../../../images/fr.png)
Un journal traitant du sujet (1520 hits)
> Lire la suite (112 commentaires, moyenne: 3,7). [dépêche : 1185 caractères]
Beagle nécessite :
- un noyau intégrant inotify (extension permettant d'être notifié lors d'une modification d'un système de fichier). Bien qu'optionnel, ce noyau est fortement recommandé pour obtenir une indexation en temps réel.
- les systèmes de fichier indexés doivent supporter xattr (là encore optionnel, mais fortement recommandé, sinon une base SQLite est utilisée mais les performances globales s'en trouvent dégradées),
- l'environnement Mono avec GTK# pour le client,
- des bibliothèques optionnelles pour supporter de nouveaux types de documents/médias : Evolution, Exif, etc.
- une machine relativement puissante : l'indexation en temps réel et en continu demande beaucoup de ressource de calcul de la part du processeur. Tentant d'être le moins intrusif possible, Beagle intègre un moniteur qui gère l'activité de l'indexation en fonction de la charge de la station de travail.
je crois que je vais m'en passer
# urpmi beagle
Un des paquetages suivants est nécessaire :
1- mono-data-sqlite-1.1.9-1mdk.i586 : SQLite database connectivity for mono (to install)
2- ml-pnet-0.6.12-1mdk.noarch : Mono Libraries for Portable.NET (to install)
Que choisissez-vous ? (1-2) 1
Pour satisfaire les dépendances, les 41 paquetages suivants vont être installés (105 Mo):
beagle-0.0.12-5mdk.i586
evolution-2.2.3-10mdk.i586
evolution-data-server-1.2.3-7mdk.i586
evolution-sharp-0.8-1mdk.i586
gal-2.4-2.4.3-1mdk.i586
galago-sharp-0.3.2-4mdk.noarch
gecko-sharp-0.6-7mdk.noarch
glade-sharp-1.0.10-1mdk.i586
glib-sharp-1.0.10-1mdk.i586
gmime-sharp-2.1.15-1mdk.noarch
gnome-sharp-1.0.10-1mdk.i586
gnome-spell-1.0.6-2mdk.i586
gsf-sharp-0.3-0.43876.1mdk.i586
gtk-sharp-1.0.10-1mdk.i586
gtkhtml-3.6-3.6.2-3mdk.i586
libchm0-0.36-1mdk.i586
libevolution-data-server4-1.2.3-7mdk.i586
libgal-2.4_0-2.4.3-1mdk.i586
libgalago-0.3.2-3mdk.i586
libgalago1-0.3.2-3mdk.i586
libgdiplus0-1.1.9-1mdk.i586
libgladesharpglue-1.0.10-1mdk.i586
libglibsharpglue-1.0.10-1mdk.i586
libgmime2.0-2.1.15-1mdk.i586
libgnomeprint-2.10.3-3mdk.i586
libgnomeprint2-2_0-2.10.3-3mdk.i586
libgnomeprintui2-2_0-2.10.2-3mdk.i586
libgnomesharpglue-1.0.10-1mdk.i586
libgtkhtml-3.6_18-3.6.2-3mdk.i586
libgtksharpglue-1.0.10-1mdk.i586
libmono-runtime-1.1.9-1mdk.i586
libmono0-1.1.9-1mdk.i586
libsoup-2.2_7-2.2.3-2mdk.i586
libwv-1.0_3-1.0.3-2mdk.i586
mono-1.1.9-1mdk.i586
mono-data-sqlite-1.1.9-1mdk.i586
perl-DB_File-1.811-1mdk.i586
perl-Mail-SpamAssassin-3.0.4-3mdk.i586
perl-XML-LibXML-1.58-2mdk.i586
perl-XML-LibXML-Common-0.13-3mdk.i586
spamassassin-3.0.4-3mdk.i586
j'ai du mal à comprendre tant de dépendance
-
[^]Re: je crois que je vais m'en passer
-
[^]Re: je crois que je vais m'en passer
Posté par Stéphane Brunner () le 16/09/2005 à 14:03. (lien). Évalué à 4.Pour KDE il y a Kat ;-) (Pas tester !)
http://www.kde-apps.org/content/show.php?content=22135(...)-
[^]Re: je crois que je vais m'en passer
Posté par Clément Schreiner (page perso, ) le 16/09/2005 à 15:00. (lien). Évalué à 10.Pourquoi est ce qu'on doit pas le tester ?
-
[^]Re: je crois que je vais m'en passer
Posté par marsup () le 16/09/2005 à 15:17. (lien). Évalué à 5.2 possibilités :
1/ tu as oublié de mettre un smiley :-)
2/ le monsieur a fait une fôte d'accord... : "pas testé"-
[^]Re: je crois que je vais m'en passer
Posté par Clément Schreiner (page perso, ) le 17/09/2005 à 20:05. (lien). Évalué à 3.Oui, j'ai oublié le smiley :)
-
-
-
[^]Re: je crois que je vais m'en passer
-
-
[^]Re: je crois que je vais m'en passer
-
[^]Re: je crois que je vais m'en passer
Posté par scls19fr (page perso, ) le 16/09/2005 à 16:19. (lien). Évalué à 5.C'est surtout des paquets Mandriva... parce que la dépendance avec Evolution... j'ai du mal à comprendre...
-
[^]Re: je crois que je vais m'en passer
Posté par gnap gnap (page perso, ) le 16/09/2005 à 16:42. (lien). Évalué à 5.En l'occurence, la description de beagle de la dépêche l'explique : « puisqu'apparement il observe en temps réel les modifications du système de fichier, les conversations dans Gaim ou les derniers courriels »
-
-
[+] [^]Re: je crois que je vais m'en passer
Posté par Aurélien Fusil () le 17/09/2005 à 00:53. (lien). Évalué à -4.Toutes ces dépendances me font penser aux dll des programmes visual basic sous windows ...
--
:(){ :|:& };:
-
-
-
[^]Re: je crois que je vais m'en passer
Posté par EppO (page perso, ) le 16/09/2005 à 13:51. (lien). Évalué à 4.DotLucene est en fait un portage du moteur de recherche Jakarta Lucene en .NET. Comme Beagle base son indexation dessus, il nécessite l'installation de mono, ce qui fait pas mal de dépendances direct. Après dans le reste, il y a beaucoup de bibliothèques optionnelles.
-
[^]Re: je crois que je vais m'en passer
Posté par TImaniac (page perso, ) le 16/09/2005 à 13:51. (lien). Évalué à 9.j'ai du mal à comprendre tant de dépendance
Facile : c'est packagé n'importe comment.
Déjà on se demande ce que vient faire Portable.NET là dedans, quand aux dépendances Gnome elles sont toutes optionnelles. Elles sont justes nécessaire pour le backend evolution.
Bon je comprend qu'on veuille simplifier la vie de l'utilisateur en installant tout, mais peut être qu'au lieu de poser une question à la con comme : Portable.NET ou mono-sqlite ? (sachant que ca n'a rien à voir), ils feraient mieux de demander : "support evolution ?"-
[^]Re: je crois que je vais m'en passer
Posté par Matthieu MARC () le 16/09/2005 à 13:57. (lien). Évalué à 2.heu, sérieusement, une question qui pour toi est simple, peut être compliqué pour d'autres.
"support evolution ?"
- heu c'est quoi ?
- le monsieur te demande si tu utilises évolution comme client de messagerie !
- heu je ne sais pas, je clique sur l'enveloppe pour lire mon courrier !
C'est dans cette optique et pour permettre à tout le monde d'utilise un PC que la question n'est pas posée.-
[^]Re: je crois que je vais m'en passer
Posté par TImaniac (page perso, ) le 16/09/2005 à 14:06. (lien). Évalué à 10.C'est dans cette optique et pour permettre à tout le monde d'utilise un PC que la question n'est pas posée.
Ben alors la logique veut que le gestionnaire regarde tout seul s'il y a Evolution sur le poste avant d'installer tout le tintouin alors que ce n'est absolument pas une dépendance NECESSAIRE.
Mais me dis pas que c'est dans une optique d'aider madame michou qu'ils ont fait ca, parcque là question qu'ils ont posé est encore plus tordu pour madame michou, n'a strictement aucun intérêt, et une réponse est fausse (la 2).
Bref, c'est vraiment mal packagé, poser une question pour savoir si on veut installer le support Evolution n'est peut être pas la meilleure solution, mais il faut un moyen de ne pas installer ce qui n'est pas obligatoire.-
[^]Re: je crois que je vais m'en passer
Posté par Matthieu MARC () le 16/09/2005 à 14:17. (lien). Évalué à 5.Ben alors la logique veut que le gestionnaire regarde tout seul s'il y a Evolution sur le poste avant d'installer tout le tintouin alors que ce n'est absolument pas une dépendance NECESSAIRE.
Logiquement, oui. Mais imagines que tu utilise thunderbird. Tu installe ensuite beagle sans support evolution. Puis ensuite, soit tu décide de migrer sur evolution, soit tu as un nouvel utilisateur sur ton système qui utilise evolution. Tu te retrouves avec evolution + beagle sans le support d'évolution.
La seule solution pour alléger ces processus c'est d'avoir un système dynamique de dépendance du genre : beagled a besoin de trucmuche si evolution est installé. Evolution a besoin de trucmuche si beagled est installé. Ca permettrait d'installer le support d'évolution de beagled en même tant que l'installation d'évolution. Vous me suivez ?-
[^]Re: je crois que je vais m'en passer
Posté par vrm (page perso, ) le 16/09/2005 à 14:24. (lien). Évalué à 9.si tu as besoin du support evolution tu installe le paquettage "beagle-evolution" ca me parait plus simple qu'un déctection moisie
-
[^]Re: je crois que je vais m'en passer
Posté par Nap () le 16/09/2005 à 14:46. (lien). Évalué à 5.et comment tu sais que tu as besoin du support evolution ? Tu vas jamais comprendre, les recherches ne montreront pas les mails (ou autre conséquence, je ne sais pas trop ce que ça fait), au début tu le verras pas, ensuite tu sauras pas pourquoi, et comme tu sais pas ce que c'est evolution ni qu'il existe un support optionnel pour evolution, tu sais pas quoi chercher, ni même qu'il faut chercher quelque chose.
J'exagère un peu, mais c'est vrai qu'il y a un problème avec les systèmes de packages traditionnels sous Linux, le manque de déclenchements d'installations en réaction à d'autres installations de paquets (pas forcément automatique, mais proposé à l'utilisateur).
La désinstallation est déclenchée automatiquement (le support evolution dépend d'évolution, donc est désinstallé lors de la désinstallation d'evolution), mais pas l'installation.-
[^]Re: je crois que je vais m'en passer
Posté par Yusei () le 16/09/2005 à 14:57. (lien). Évalué à 7.Apt, et probablement d'autres systèmes de packages, permettent de recommander et de suggérer des paquets. Et donc, quand tu installes Evolution, il est tout à fait envisageable que ton gestionnaire de paquet te suggère d'installer le support pour Beagle.
Il serait encore plus agréable de pouvoir dire "si Beagle alors proposer Support Evolution", mais ça devient compliqué :)-
[^]Re: je crois que je vais m'en passer
Posté par Nap () le 16/09/2005 à 15:48. (lien). Évalué à 0.Pour moi ça n'est pas vraiment satisfaisant :
- ces informations sont contenues dans le paquet evolution, on ne peut pas mettre à jour le paquet avec pour chaque plugin existant en lien avec une autre appli, c'est ingérable
- si, comme tu le dis, ça ne va pas regarder si beagle est installé, alors ça va te proposer tous les plugins possibles même si ceux-ci n'ont aucune raison de t'intéresser car tu n'as pas l'appli en question d'installée. En plus, certains paquets proposés vont alors ramener 150 Mo de dépendances.
Il faudrait donc que le paquet beagle-evolution declare lui-même qu'il est intéressant lorsque beagle et evolution est installé. Comme ça, en installant evolution, le système de paquets cherche puis propose à l'utilisateur tous les paquets "intéressants" pour evolution, et pour lesquels tous les autres applications pour lesquelles ils ont un sens sont installées.
Avec un bon index, c'est rapide.-
[^]Re: je crois que je vais m'en passer
Posté par Yusei () le 16/09/2005 à 18:15. (lien). Évalué à 2.ça ne va pas regarder si beagle est installé, alors ça va te proposer tous les plugins possibles même si ceux-ci n'ont aucune raison de t'intéresser car tu n'as pas l'appli en question d'installée.
Mais peut-être que je ne connaissais pas Beagle, et qu'en découvrant qu'il peut indexer mes emails je vais trouver ça intéressant. Pour moi c'est une feature, de suggérer les plugins les plus populaires.
Et si je choisis d'installer le plugin beagle-evolution, ça installe beagle, donc tout va bien.
En plus, certains paquets proposés vont alors ramener 150 Mo de dépendances.
Les paquets recommandés ou suggérés ne sont pas installés d'office, ils sont tous en option. Je ne comprends pas ta remarque: quelle que soit la manière dont on suggère à l'utilisateur d'installer un truc, s'il n'a pas les dépendances il va bien falloir les installer.-
[^]Re: je crois que je vais m'en passer
-
-
-
[^]Re: je crois que je vais m'en passer
Posté par Michel Galle () le 17/09/2005 à 12:34. (lien). Évalué à 7.tenez le pour acquis ; LA MAJORITE Des utilisateurs d'ordinateurs (quasi tous) ne SAVENT PAS s'ils ont besoin du "support evolution pour beagle" et autres questions farfelues du genre "allez vous lire du AAC ?" !!!
faut arrêter de croire cela !
c'est bon pour des développeurs unix et des gens qui connaissent les arcanes, ce n'est PAS bon pour les utilisateurs
je n'ai même pas envie de me fatiguer à savoir les détails des paquetages de ubuntu quand je veux installer un logiciel
d'ailleurs, une bonne distribution doit _fournir_ ce genre d'outils (beagle) de _Base_ avec à chaque application installée le nécessitant le support nécessaire. SANS ME DEMANDER , je n'ai PAS le temps de répondre à des questions techniques comme cela avec des mots en anglais bizarres, je bosse.
que apt fasse le boulot, c bien
que apt pose des questions arcanes c'est MAL (sauf si on souhaite tout savoir, mais là vous êtes experts et vous savez activer ce qu'il faut)
enfin bref, là c'est pour tester
quand tout sera intégré dans les ubuntu, les mandriva etc quand tout sera mature, la question n'existera plus du tout.-
[+] [^]Re: je crois que je vais m'en passer
Posté par wismerhill (page perso, ) le 17/09/2005 à 13:46. (lien). Évalué à -2.Tu devrais plutôt utiliser MacOS.
-
[^]Re: je crois que je vais m'en passer
-
-
[^]Re: je crois que je vais m'en passer
Posté par LupusMic (page perso, ) le 17/09/2005 à 21:23. (lien). Évalué à 6.C'est pourquoi lorsque tu installe une Debian la première fois, il te demande si tu veux les question critiques ou jusqu'à non critiques. En fonction du niveau choisit, tu auras les qustion en conséquence.
Maintenant, il serait bien qu'il y ait des dépendances multiples. Style : j'installe Evolution un jour, puis un autre jour il m'installe Beagle... et là Apt pourrait me proposer d'installer le paquet qui fait la jonction... à ben il le propose déjà. Mince.
-
-
-
[^]Re: je crois que je vais m'en passer
Posté par Zakath (page perso, ) le 16/09/2005 à 18:51. (lien). Évalué à 2.D'où l'intérêt des variables USE dans gentoo.
Ton package te proposera une USE "evolution" que tu verras au moment d'emerger (si tu as le bon sens de toujours faire des emerge -av) et qui te permettra 1) d'être conscient de l'existence d'un support d'evolution 2) de l'installer ssi tu le veux.-
[^]Re: je crois que je vais m'en passer
Posté par yoho (page perso, ) le 24/09/2005 à 08:23. (lien). Évalué à 2.Oui, et ta variable USE fait 18 km de long : oui, je veux le support MMX pour mes applis, oui j'ai une librairie qui lit les png, etc... et si on se trompe, il faut recompiler la moitié de ses paquetages... non merci.
-
-
-
[^]Re: je crois que je vais m'en passer
Posté par Matthieu MARC () le 16/09/2005 à 14:46. (lien). Évalué à 2.hum... tu l'installes quand ?
Parce que dans mon post précédent, je disais que beagle était installé avant évolution sans le support évolution....
-
-
-
[^]Re: je crois que je vais m'en passer
Posté par Zorro () le 16/09/2005 à 14:25. (lien). Évalué à 2.C'est Michu. Madame Michu. Pas Michou.
-
[^]Re: je crois que je vais m'en passer
Posté par boubou (page perso, ) le 16/09/2005 à 16:08. (lien). Évalué à 1.Oui, surtout que Michou, c'est un monsieur.
-
[^]Re: je crois que je vais m'en passer
-
-
-
-
-
[^]Re: je crois que je vais m'en passer
Posté par Matthieu C () le 16/09/2005 à 15:54. (lien). Évalué à 2.j'ai du mal à comprendre tant de dépendance
Facile : c'est packagé n'importe comment.
C'est louche, sous debian, y a aussi autant de dependance [1]...
Le choix ne s'effecturait pas a la compilation ?
[1]
Depends: libatk1.0-0 (>= 1.9.0), libc6 (>= 2.3.5-1), libgcc1 (>= 1:4.0.1), libglib2.0-0 (>= 2.8.0), libgtk2.0-0 (>= 2.6.0), libice6 | xlibs (>> 4.1.0), libpango1.0-0 (>= 1.8.2), libsm6 | xlibs (>> 4.1.0), libstdc++6 (>= 4.0.1), libx11-6 | xlibs (>> 4.1.0), libxss1, mono-jit (>= 1.1.8.2), libevolution-cil (>= 0.8), libexif12, libgconf-cil (>= 1.0), libgecko-cil (>= 0.6), libglade-cil (>= 1.0), libglib-cil (>= 1.0), libgmime2.1-cil, libgnome-cil (>= 1.0), libgnomeui-0 (>= 2.8.0), libgnomevfs2-0 (>= 2.10.0-0), libgtk-cil (>= 1.0), mono-classlib-1.0 (>= 1.0), dbus-1-utils, libsqlite0, libmono0 (>= 1.0)-
[^]Re: je crois que je vais m'en passer
Posté par gnap gnap (page perso, ) le 16/09/2005 à 16:44. (lien). Évalué à 8.« C'est louche, sous debian, y a aussi autant de dependance [1]... »
Non non, c'est pas louche. Quand il est devenu habituel de critiquer à tout va une distrib, l'habitude vient aussi de ne plus chercher à comprendre ce qu'elle fait et propose, mais d'emblée de considérer que c'est médiocre.
Je trouve cela assez lamentable, au final.
-
[^]Re: je crois que je vais m'en passer
Posté par gnumdk (page perso, ) le 16/09/2005 à 17:46. (lien). Évalué à 4.Ben non, ca n'a aucun rapport, debian installe libevolution-cil , pas evolution.
Ca c'est encore un gros probleme avec Mandriva qui meme si en avance sur redhat a besoin de continuer à découper ses packages.
Voila les packages evolution sous debian:
evolution - The groupware suite
evolution-data-server - evolution database backend server
evolution-data-server-dev - Development files for evolution-data-server (meta package)
evolution-dev - Development library files for Evolution
evolution-exchange - Exchange plugin for the Evolution groupware suite
evolution-plugins - All bundled plugins for Evolution 2.2
evolution-webcal - webcal: URL handler for GNOME and Evolution
libebook1.2-3 - Client library for evolution address books
libebook1.2-dev - Client library for evolution address books (development files)
libecal1.2-2 - Client library for evolution calendars
libecal1.2-dev - Client library for evolution calendars (development files)
libedata-book1.2-2 - Backend library for evolution address books
libedata-book1.2-dev - Backend library for evolution address books (development files)
libedata-cal1.2-1 - Backend library for evolution calendars
libedata-cal1.2-dev - Backend library for evolution calendars (development files)
libedataserver1.2-4 - Utily library for evolution data servers
libedataserver1.2-dev - Utility library for evolution data servers (development files)
libedataserverui1.2-4 - GUI utily library for evolution data servers
libedataserverui1.2-dev - GUI utility library for evolution data servers (development files)
libevolution-cil - CLI bindings for Evolution
-
-
[^]Re: je crois que je vais m'en passer
Posté par Misc (page perso, ) le 16/09/2005 à 22:41. (lien). Évalué à 6.> Facile : c'est packagé n'importe comment.
> Déjà on se demande ce que vient faire Portable.NET là dedans, quand aux
> dépendances Gnome elles sont toutes optionnelles. Elles sont justes nécessaire
> pour le backend evolution.
Elles sont surtout tirés par des dépendances automatiques.
Idéalement, il suffirait en effet de séparer le paquet. À condition de trouver ce qui tire la dépendance, si le soft marche vraiment encore sans ça, si ça nécessite pas de tout changer ailleurs.
Dans la mesure ou beagle est en version 0.0.12, je peut comprendre que le mainteneur a à faire des trucs plus important que pousser la finesse du packaging dans ses derniers retranchements.
Parce que je rappelle qu'il faut de temps à autre faire des releases ( ie pas une fois tout les 10 ans ), et qu'avec des ressources limités ( ie pas 500 devs ), tu doit agir en fonction des priorités.
> Bon je comprend qu'on veuille simplifier la vie de l'utilisateur en installant tout,
> mais peut être qu'au lieu de poser une question à la con comme : Portable.NET ou
> mono-sqlite ? (sachant que ca n'a rien à voir), ils feraient mieux de demander :
> "support evolution ?"
Et au lieu de le dire sur linuxfr, peut etre que faire un truc constructif, comme le reporter sur le bugzilla, ça aiderais le mainteneur qui a surement pas vu que beagle pose une question con ( car elle ne sera pas posé si un des deux paquets existe ) ni que le paquet tire tant de chose ?
Si on était pas en freeze, j'aurais même rectifié moi même, mais je comprends qu'il est parfois plus facile de poster sur un site de news en francais que de le faire sur un site de rapport de bugs en anglais.
-
-
[^]Re: je crois que je vais m'en passer
Posté par Matthieu MARC () le 16/09/2005 à 13:54. (lien). Évalué à 2.beagle-0.0.12-5mdk.i586
evolution-2.2.3-10mdk.i586
evolution-data-server-1.2.3-7mdk.i586
evolution-sharp-0.8-1mdk.i586
Beagle a plusieurs fonctionnalités. Par défaut, ta distrib te les fournit tous. Par exemple, beagle peut parser tes mails si tu utilises evolution. Ca n'a pas l'air, vu qu'évolution n'a pas l'air d'être déjà installé. Tant pis pour toi, il va l'installer. Mais bon, évolution a aussi des dépendances sur d'autres paquetages (evolution-sharp ou evolution-data-server par exemple).
mono-data-sqlite-1.1.9-1mdk.i586
Comme dis dans l'annonce, beagle peut utilise une base de données sqlite, ce n'est pas conseillé, mais c 'est possible. Du coup, il a besoin du support sqlite.
spamassassin....
Evolution utilise spamassassin pour la recherche des pourriels. Sûrement que quand tu installe evolution, ça installe spamassassin en même temps (si c'est le cas, c'est une politique de mandriva).
Voila voila
A mon avis, tous les paquetages que tu as listés ne sont pas directement demandé par beagle. Un peu comme quand tu trouves un petit bout de corde sur la plage, tu tires, et au final, tu te retrouves avec 1km de corde !
-
[^]Re: je crois que je vais m'en passer
Posté par Zorro () le 16/09/2005 à 14:24. (lien). Évalué à 2.Pareil. J'avais essayé de l'installer y a quelques mois sur une Cooker. Des tonnes de téléchargement pour un truc qui finalement ne marchait pas.
Mais patience, quand ça serait proprement intégré dans les distro, ça sera de la balle, vu les démos en Flash qu'on voit sur le site officiel.-
[^]Re: je crois que je vais m'en passer
Posté par Yusei () le 16/09/2005 à 15:00. (lien). Évalué à 2.Pour ceux qui veulent essayer rapidement sans se casser la tête, je crois qu'Ubuntu a l'intention d'intégrer Beagle dans sa prochaine release (et donc on pourra l'utiliser avec le Live-CD). Par contre, je ne sais pas si la prochaine release en question est Breezy Badger ou la suivante.
Il y a quelques temps je m'étais "amusé" à installer Beagle 0.0.x sur ma Debian, c'était assez bugué mais quand ça marchait, qu'est-ce que c'était bien...-
[^]Re: je crois que je vais m'en passer
Posté par Matthieu MARC () le 16/09/2005 à 15:58. (lien). Évalué à 3.pas la peine d'attendre la prochaine version d'ubuntu, il suffit de se rendre sur le site ubuntu fr, il y a une documentation bien écrite sur l'installation de beagle.
http://wiki.ubuntu-fr.org/applications/beagle(...)
-
[^]Re: je crois que je vais m'en passer
Posté par Erwan (page perso, ) le 16/09/2005 à 16:21. (lien). Évalué à 2.Breezy est deja disponible en preview release, Beagle s'installe en une ligne d'apt-get et ca marche tres bien.
-
-
-
[^]Re: je crois que je vais m'en passer
Posté par CrEv (page perso, ) le 17/09/2005 à 12:20. (lien). Évalué à 2.Vu que beagle est fait pour gnome, il me semble normal que ça demande autant de dépendances. Si on installe un prog kde sur une machine n'ayant pas kde ça produitle même effet... mais bon, 100Mo de plus ou de moins ...
(enfin, je parle de la partie interface intégrée à gnome, pas du core)
Mais il y a encore mieux :
# urpmi beagle
Afin de poursuivre la mise à jour, les paquetages suivants doivent être désinstallés :
epiphany-1.4.8-8mdk.x86_64 (pour installer le paquetage epiphany-1.4.8-8mdk.i586)
mozilla-firefox-1.0.2-3mdk.x86_64 (pour installer le paquetage mozilla-firefox-1.0.2-3mdk.i586) (o/N)
ralala les bienfait d'une plateforme 64 bit ;)-
[^]Re: je crois que je vais m'en passer
Posté par Panda Voyageur (page perso, ) le 17/09/2005 à 14:57. (lien). Évalué à 1.> ralala les bienfait d'une plateforme 64 bit ;)
En voyant ça, j'apprécie encore plus les distribs source-based, qui n'ont pas de telles séparations au niveau du package :)
(bon ya aussi le coup des USE flags, mais ça a déjà été évoqué largement avec l'install rpm qui amène tout le train evolution avec lui!)
-
Kat
À noter également, l'existence de Kat, équivalent de Beagle pour KDE (encore très largement en dev, visant l'intégration à KDE 4.0). http://www.kde-apps.org/content/show.php?content=22135(...)
Wr ar fbhunvgr cnf ha qrfgva sharfgr à yn cncnhgé. Nzra.
-
[^]Re: Kat
Posté par Nicolas (page perso, ) le 16/09/2005 à 14:36. (lien). Évalué à 4.KDE 4 intégrera Tenor, qui sera partiellement basé sur Kat, d'après ce que j'ai compris.
Pour les différences entre Tenor et Beagle, voilà un peu de lecture :
http://dot.kde.org/1113428593/1113438483/(...)
J'ai hâte de voir ça.-
[^]Re: Kat
Posté par TImaniac (page perso, ) le 16/09/2005 à 14:41. (lien). Évalué à 5.Et voilà, encore un framework indépendant de tout toolkit graphique (et donc de Gnome et KDE) qui aurait pu voir les différents efforts rassemblés.
Et bien non. Il faut que KDE assimile Beagle à Gnome (alors que Beagle supporte désormais KDE, reste plus qu'à écrire des plugins), et que donc naturellement ils faut qu'ils réinventent la roue plutôt que de participer à Beagle en apportant leurs bonnes idées (sauvegarde du contexte).-
[^]Re: Kat
Posté par lezardbreton (Jabber id, page perso, ) le 16/09/2005 à 14:48. (lien). Évalué à 10.Kat est pas tout jeune non plus, ne dépend pas de mono, permettra de mettre un vrai framework au sein de KDE. Bref, il a toutes les raisons d'exister...
-
[^]Re: Kat
Posté par Krunch (Jabber id, page perso, ) le 17/09/2005 à 00:06. (lien). Évalué à 4.Si Kat ne dépend pas de mono mais qu'il dépend de libkde$BLA, ça avance pas plus les utilisateurs non KDEistes (il n'y a pas que les utilisateurs de Gnome et KDE qui pourraient bénéficier d'un logiciel comme celui là).
Bon maintenant je me trompe peut-être complétement et Kat ne dépend pas du tout de 50Mo de libs KDE mais j'ai un sale doute quand même (et j'ai la flemme de vérifier).--
Free Softwares Users Group Arlon (Sud Luxembourg, Belgique)
pertinent, e adj. Approprié ; qui se rapporte exactement à ce dont il est question.-
[^]Re: Kat
Posté par lezardbreton (Jabber id, page perso, ) le 17/09/2005 à 08:58. (lien). Évalué à 5.Oui, tu as raison. A priori, Kat ne sera pas fait pour être utilisé en dehors de KDE, c'est le revers de la médaille. La logique est compréhensible en même temps : les développeurs passent beaucoup de temps à créer un bureau homogène et intégré, et soit ne pensent pas, soit n'ont pas le temps de penser aux autres environnements. Je suis régulièrement sous XFCE4, et j'aimerais bien profiter de ces développements, mais je sais que je suis en dehors de l'objectif.
-
[^]Re: Kat
Posté par Frédéric COIFFIER () le 20/09/2005 à 13:32. (lien). Évalué à 4.Je pense surtout que les devéloppeurs de KDE doivent actuellement changer beaucoup de chose pour KDE4.
Donc, autant intégrer le principe de Kat au coeur de KDE pour offrir facilement ses services à toutes les applications qui viendront au-dessus. Ainsi avec un minimum d'effort, les développeurs d'appli de KDE pourront profiter des services d'indexation.
C'est la force et le choix de KDE : fournir des interfaces et des services pour renforcer l'intégration entre les applications.-
[^]Re: Kat
Posté par TImaniac (page perso, ) le 20/09/2005 à 13:41. (lien). Évalué à 3.Ce choix est tout à fait pertinent : proposer une intégration de Kate dans KDE est tout à fait louable. Mais ce qui aurait été cool c'est que Kate reste indépendant de KDE, et que KDE utilise Kate comme une bibliothèque, qui elle serait exploitable depuis n'importe quelle application, même une application Gnome, un peu comme Beagle qui propose ses services à travers D-Bus, et donc exploitable entre autre par des applis KDE ou Gnome.
-
[^]Re: Kat
Posté par Ph Husson (page perso, ) le 20/09/2005 à 15:17. (lien). Évalué à 3.Plutot kat que kate... parce que bon kate c'est bien comme éditeur de texte mais bon pour indexed des fichiers c'est autre chose :D
-
[^]Re: Kat
Posté par yoho (page perso, ) le 24/09/2005 à 08:41. (lien). Évalué à 2.C'est parceque tu ne connais pas encore les possibilités de kat que tu dis ça. En gros, ça ne peut dépendre que de KDE puisque chaque application KDE pourra en bénéficier.
C'est encore en préparation, mais imagine que tu es sous kword et que tu veux ouvrir un fichier. Tu te rappelles juste qu'il parle de "linux" et "beagle" : tu fais ouvrir, t'as un petit champ "recherche avec kat" et pof ! tu trouves ton document sans quitter kword.
Tu es sous konqueror et tu veux les photos prises entre le 14 et le 18 juilet : lance une recherche kat...
Les posibilités d'intégration sont beaucoup plus grande quand on connait l'environnement graphique. Windows Vista utilisera des dossiers virtuels : un dossier qui contient tout tes mp3, un sous-dossier qui contient tout tes mp3 de tel artiste, etc... Kat rendra cela possible.-
[^]Re: Kat
Posté par TImaniac (page perso, ) le 24/09/2005 à 09:39. (lien). Évalué à 4.N'importe quoi.
Je vois pas du tout ce qui empêche d'avoir le même modèle que Beagle, à savoir un modèle client server avec notion de plugins.
Beagle est indépendant de KDE ou Gnome, c'est le moteur d'indexation et de recherche. S'ajoute des clients qui s'intègre graphiquement dans Gnome ou KDE, et des plugins pour le serveur qui lui permettent d'accéder à Gaim, à GnomeVFS, à Konqueror, etc.
Gros intérêt : la partie difficile, Beagle est indépendante et réutilisable. De plus pour les personnes qui ont les 2 environnements (Gnome et KDE), ils peuvent partager le même index, avec un seul daemon, bref c'est l'idéal.
Le seul truc de Kat qui fait la différence c'est qu'ils ont dit qu'ils allaient faire pareil mais en "mieux", avec l'aspect "contextuel". Je trouve ca dommage de se diriger vers des choix qui feraient que ce soit utilisable uniquement sous KDE alors que techniquement cette valeur ajoutée n'est ABSOLUMENT PAS dépendant de KDE.
Tu prends l'exemple de Vista : ben chez Microsoft ils savent mieux faire la séparation entre Environnement graphique et moteur d'indexation/Recherche, la preuve en est que le bousin, WinFS, sera backporté sous Windows XP.-
[^]Re: Kat
Posté par yoho (page perso, ) le 25/09/2005 à 04:54. (lien). Évalué à 3.Kat veut être plus qu'un moteur de recherche, comme tu le dis. Ce n'est possible qu'en l'intégrant à KDE.
Quel aurait été l'intérêt de reprendre le modèle de Beagle puisque Beagle fonctionne très bien sous KDE, comme tu le dis ? (Enfin j'attend toujours des plugins pour les applis KDE, humhum... et je crois que je vais pouvoir attendre longtemps)
C'est quoi le rapport avec le backport d'une appli de Windows vers Windows ? On peut sûrement backporter kat vers KDE 3.3 aussi, mais je ne vois pas du tout ce que ça prouverait...-
[^]Re: Kat
Posté par TImaniac (page perso, ) le 25/09/2005 à 17:06. (lien). Évalué à 1.KDE 3.3 et KDE 4 sont très proche d'un point de vue technologique, pas du tout le même gouffre technologique qu'entre Windows XP et Vista.
Ensuite même si Kat veut ajouter le modèle "contextuel", je ne vois pas ce qui le différencie de Beagle sur les objectifs. Et je ne vois absolument pas en quoi ce modèle "contextuel" serait dépendant de KDE.
Beagle et KAt ont de nombreux objectifs en communs, de nombreuses solutions en communs, tu pourras dire tout ce que tu veux mais ca restera toujours idiot de ne pas chercher à mettre en commun ce qui peut l'être, tout ca par simple choix technique en enfermant Kat dans un environnement particulier.
Enfin j'attend toujours des plugins pour les applis KDE, humhum... et je crois que je vais pouvoir attendre longtemps
Ben oui mais là c'est à cause d'un point de vue idéologique, parcque justement les KDéistes (marrant ce mot) préfère se la péter en disant "oué ca pu le Gnome et le mono, nous on va faire pareil mais en ouachement mieux, on va réinventer la roue mais on va ajouter des jantes en alu, et les roues ne seront pas standards, elles ne rouleront que sur les goudrons KDE". Yahoo. Effectivement en partant de ce principe tu risques pas de voir beaucoup de plugin KDE pour Beagle, alors que techniquement c'est tout à fait faisable.
-
-
-
-
-
-
-
-
-
[^]Re: Kat
Posté par boubou (page perso, ) le 16/09/2005 à 16:10. (lien). Évalué à 4.Je crois surtout que Beagle est implémenté en C#, ce qui pose des problèmes graves de licences, brevets, etc. cf mon merveilleux papier de linux mag, maintenant en ligne http://apiacoa.org/publications/2004/lm-java-dotnet-free.pdf(...)
Timaniac, je ne répondrai pas à tes trolls.-
[^]Re: Kat
Posté par TImaniac (page perso, ) le 16/09/2005 à 16:37. (lien). Évalué à 1.Allez, répètes après moi :
"MS détient plus de brevets sur le kernel Linux que sur Mono"
-
-
[^]Re: Kat
Posté par Erwan (page perso, ) le 16/09/2005 à 16:25. (lien). Évalué à 3.Pour le moment Beagle ne fait pas partie de Gnome (a cause de C# justement), et avec entre autres RedHat et Sun (deux gros contributeurs) opposes a l'integration de Mon dans Gnome, c'est pas pres d'arriver.
Donc pour rassembler les efforts, c'est mal barre :)
-
[^]Re: Kat
Posté par gnumdk (page perso, ) le 16/09/2005 à 17:56. (lien). Évalué à 4.Ben non, ils réinventent pas la roue! En clair, ce qui interesse actuellement les gens de Kde avec Tenor, c'est le contexte des informations, pas d'écrire un bête indexeur. Un peu comme Winfs sauf que pour l'instant Microsoft a l'air de penser que l'utilisateur n'aura que ca a foutre à faire des associations entres ses fichiers. Après ca me semble un projet très ambitieux mais on verra bien !
Sinon pour beagle y'a ca :
http://www.kde-apps.org/content/show.php?content=28437(...)
Interview de Aaron Seigo :
Well, I one thing that I would add ... a couple of things that are happening in the Appeal project that we didn't really get to discuss thus far taht I find really interesting are, one: the contextual link enginge. We were talking previously by email, you had asked is there a search engine sort of thing coming around. And search tools are a really hot topic right now. It seems every desktop environment is throwing up a search tool. In the KDE project I think in the last two months I've seen three or four different approaches from people that are working on it on their own. We think that's kind of just the first step and that what's a lot more compelling than saying, "Let's throw all the full text and all the meta data into a big glop database and let you full text search it" is the ability to record, mine and then go back and navigation and search through contextual relationships between information.
It's funny how much information we throw away on the desktop. Insane amounts of information. If you're doing research on the Internet, for instance.. An example I've used is say you're doing an essay on panda bears. You go on the 'net, you go to ilovepandabears.com, find an image you really want to use in your presentation, you download that image. When that image is downloaded to your disk, we no longer know where it came from. We've lost a bit of context for that image. Then you take that image and you put it in your word processing document. We have lost yet more of the context because we really no longer know that that image is actually the same image as the one that's on disk and that it actually came from the Internet, in fact it actually came from this website.
We're looking at capturing that sort of information and allowing the user to actually navigate and move through their information using that contextual web. Uou look at Google, that was how they broke through: they use their whole page ranking thing. The idea of context being more important even than the content of the actual information you're looking at. And if you examine how we use groupware or how we build word processing documents or slide presentations, media files, the whole bit there's a lot of context that were not allowing people to gather.
We don't allow people to annotate information freely and then collect those annotations. We have these sticky notes, KNotes or whatever, that you stick randomly in places on screen that aren't semantically connected to anything.
The contextual linking engine, which is called Tenor, allows us to start bridging that gap. It really starts allowing us to provide context-based, in other words informational or meaning based, searching and navigation on the desktop. And this is widely applicable from things like KControl and the relationships between the different panels to managing your files in a content manager to your address book: Who is Jane Doe andw hat is she associated with in your life?-
[^]Re: Kat
Posté par gnumdk (page perso, ) le 16/09/2005 à 18:15. (lien). Évalué à 2.Merde, j'avais pas vu que tu parlais du contexte à la fin de ta phrase ;)
Certe, il aurait pu participer à beagle pour ammener leur bonne idée, mais beagle c'est du gros C# et ils ont peut être pas envie de coder en C#.
-
-
-
-
[^]Re: Kat
Posté par lezardbreton (Jabber id, page perso, ) le 16/09/2005 à 14:44. (lien). Évalué à 7.Exactement, sauf que kat a choisi d'être intelligent, et ce n'est donc pas juste un projet isolé.
Kat a pour le moment une ergonomie pourrie, car son but n'est pas seulement de devenir une interface de recherche, mais d'être un framework qui pourra être partagé par de nombreuses applications. On peut donc penser son interface actuelle comme une 'proof of concept' permettant de tester son fonctionnement interne.
Un de ses dev principal en parle ici : http://robertocappuccio.blogspot.com/(...)
Un des enthousiastes, c'est Gael Duval, qui en parle ici : http://www.indidea.org/gael/fr/(...)
Pour l'instant, ce n'est pas encore mature, c'est pour ça que je pense que c'est une connerie de l'activer par défaut sur la Mandriva 2006.-
[^]kat / beagle / lucene
Posté par Antoine () le 18/09/2005 à 11:57. (lien). Évalué à 7.Le truc le plus ennuyeux :
- Lucene est un moteur d'indexation écrit en Java par la fondation Apache
- beagle utilise une exacte réécriture en C# de Lucene
- kat utilise une exacte réécriture en C++ de Lucene
J'espère que dans quelques années on ne se retrouvera pas avec trois versions réécrites de chaque bibliothèque sur nos systèmes ("c'est pas mon langage préféré").-
[^]Re: kat / beagle / lucene
Posté par cedric () le 18/09/2005 à 16:15. (lien). Évalué à 4.Il aurait du la faire en C et faire des bindings pour tous les langages apres, ca aurait eviter les dependances externes inutiles et les problemes de ce langage ne me plait pas...
Quelqu'un pour faire un fork en C ? ;)-
[^]Re: kat / beagle / lucene
Posté par wismerhill (page perso, ) le 18/09/2005 à 16:45. (lien). Évalué à 2.Ben, d'un point de vue java ça a un sens de le faire en tout java, comme ça il n'y a qu'un jar à distribuer et pas besoin d'en faire une version pour chaque plateforme.
Mais à partir du moment où on veut s'en servir dans d'autres langages ça devient ennuyant.-
[^]Re: kat / beagle / lucene
-
-
[^]Re: kat / beagle / lucene
Posté par -=[ Benoit Plessis ]=- (page perso, ) le 19/09/2005 à 14:23. (lien). Évalué à 5.Y a deja: CLucene.
Pis ya PLucene (perl), PyLucene (Binding Python via gcj+swig), etc etc.--
Il [e2fsck] a bien démarré, mais il m'a rendu la main aussitot en me disant "houlala, c'est pas beau à voir votre truc, je préfèrerai que vous teniez vous même la tronçonneuse" (traduction libre)
-
-
[^]Re: kat / beagle / lucene
Posté par golum () le 20/09/2005 à 07:46. (lien). Évalué à 2.Au fait , l'interêt de Mono, c'est pas de permettre de partager des composants et de les faire communiquer indépendamment du langage ?
-
[^]Re: kat / beagle / lucene
Posté par Ph Husson (page perso, ) le 20/09/2005 à 15:19. (lien). Évalué à 2.Tous Touss c'est de la bonne toi :p
Tu confonds peut etre avec dbus?
Enfin en tout cas y a rien qui correspond directement à ta déscription-
[^]Re: kat / beagle / lucene
Posté par CrEv (page perso, ) le 20/09/2005 à 16:20. (lien). Évalué à 3.non, il a raison (enfin presque)
l'un des arguments de .net est justement de pouvoir s'affranchir du langage dans lequel une application a été réalisée du moment qu'il peut se compiler en il par .net
Par exemple, créer une appli donc le coeur (les calculs) serait en fortran, cobol ou n'importe quoi et l'interface en vb (beurk).
J'avais assisté à une prez .net et le gars s'amusait justement à linker des élements de plusieurs langages ensemble. Je crois qu'on peut aussi faire de l'héritage indépendement des langages.
Bon, par contre, je ne pense pas que mono le puisse, simplement parce que mono c'est surtout c# (je crois qu'il y avait aussi du vb, mais j'ai jamais regardé je déteste ça ;))-
[^]Re: kat / beagle / lucene
Posté par TImaniac (page perso, ) le 22/09/2005 à 08:42. (lien). Évalué à 5.Mono/.NET implémente la CLI (Common Language Infrastructure) définie à l'ECMA, dont le nom veut bien dire ce qu'il veut dire :)
Un langage qui veut cibler la CLI doit répondre aux CLS (Common Langage Specification) qui défini en gros les règles que doivent définir un langage pour s'intégrer avec la CLI (définition d'un objet, héritage, etc.) et rendre un composant indépendant du langage dans lequel il a été développé pour qu'il puisse être réutiliser facilement.
Aux CLS est associé le CTS (Common Type System) qui défini les types simples partagés par tous les langages (Int32, Float, etc.), toujours dans le but de permettre l'indépendance du langage et du code produit.
Dans la pratique avec le framework .NET on a généralement du code généré à partir des langages fournis par Microsoft : C#, VB.NET, J#, C++ managed, JScript. Auquels s'ajoutent de nombreux langages qui ne viennent pas de Microsoft (comme Delphi par exemple).
Mono propose un compilateur C# abouti, un compilateur VB.NET qui reste à travailler, et un compilateur JScript pas vraiment mature :)
A côté de cela d'autres projets OpenSource ont fait leur apparition pour développer d'autres langages qui ciblent notamment Mono : Nemerle ou Boo par exemple.
La plupart des langages qui ciblait initialement le framework .NET produise du code qui tourne sans problème avec Mono, par contre il n'y a pas toujours de compilateur sous Linux. Parfois le compilateur est lui-même écrit pour .NET et tourne donc avec Mono, c'est le cas de IronPython, une implémentation de Python.
Dans tous les cas, si un compilateur produit du code pour la CLI, il tournera sur Mono et .NET et sera compatible avec tous les autres langages/compilateur puisque l'unité de réutilisation est le code intermédiaire commun à tous les langages.
La force de la CLI par rapport à d'autres environnement comme Java par exemple (qui peut lui aussi être ciblé par différents langages) est de fournir des spécifications qui garantissent l'interopérabilité et l'indépendance du code produit.
-
-
[^]Re: kat / beagle / lucene
Posté par golum () le 20/09/2005 à 19:19. (lien). Évalué à 2.C'est vrai que je me suis mal exprimé.
Ce que je voulais souligner, c'est le principe de la réutilisabilté d'un composant logiciel (au sen large) entre différents langages que ce soit au travers
- d'un binding ,
-d'un runtime comme c'est le cas pour Java
http://flp.cs.tu-berlin.de/~tolk/vmlanguages.html(...)
- d'un langage intermédiaire compilé comme IL/Mono
http://linuxfr.org/2004/07/02/16698.html(...)
- depuis un bus de communication objet distribués comme les ORB Corba ou Ice
http://www.zeroc.com/ice.html(...)
- ou encore d' un bus à usage "local" comme Dbus,
XPcom de Mozilla ou encore UNO
http://lwn.net/Articles/139716/(...)
dont les deux derniers ont l'avantage d'être portables
Bref, pourquoi toujours réinventer la roue alors qu'on a déjà pléthore d'offres en terme de réutilisabilité ?
-
-
-
-
y a des progres a faire et faut que je devienne riche
1 - ca marche pas bien ce truc, malgre le lancement du daemon 24h avant il est incapable de trouver un fichier par son nom dans le home directory. Il est tout aussi incapable de trouver un type de fichier (des mp3 lors de mon test). Je dois pas utiliser la bonne syntaxe de recherche (*.mp3 .mp3 mp3). C'est clairement fait pour madame michou ce soft.
2- comme le dit la news ca en bouffe du cpu... enfin beagle ou mono car le process qui me ralentissait tout mon pc il s'appelait mono...
Enfin bon c'est l'avenir parait il...
-
[^]Re: y a des progres a faire et faut que je devienne riche
Posté par TImaniac (page perso, ) le 16/09/2005 à 14:33. (lien). Évalué à 6.1 - T'as quoi comme système de fichier ? Si t'as un système de fichier qui est normalement supporté, que tu as un kernel inotify, alors peut être as-tu trouver un bug :) Auquel cas il serait plus intelligent d'aller le reporter plutôt que de faire de l'ironie à 2 balles.
-
[^]Re: y a des progres a faire et faut que je devienne riche
Posté par Nicolas () le 16/09/2005 à 14:55. (lien). Évalué à 2.et je met quoi dans mon bug report?
Salut les gars, je suis sous linux ubuntu breezy, kernel 2.12 de ubuntu. Systeme de fichier ext3 et beagle n'arrive pas a trouver le moindre fichier existant dans mon home directory?
Ca fit pas hyper descriptif tout de meme ca....-
[^]Re: y a des progres a faire et faut que je devienne riche
Posté par TImaniac (page perso, ) le 16/09/2005 à 15:52. (lien). Évalué à 2.man beagled
(y'a des options de debug/log qui fourniront des informations plus intéressantes)
-
-
-
[+] [^]Re: y a des progres a faire et faut que je devienne riche
Posté par bz31 (page perso, ) le 16/09/2005 à 14:38. (lien). Évalué à -1.Pour le point 2, je confirme aussi.
Je compare l'utilité de beagle à la transparence proposée par Xorg ...-
[^]Re: y a des progres a faire et faut que je devienne riche
Posté par bz31 (page perso, ) le 16/09/2005 à 14:47. (lien). Évalué à 3.Pardon, je voulais dire "utilisabilité", et non pas "utilité".
-
-
[^]Re: y a des progres a faire et faut que je devienne riche
Posté par Gilles Dartiguelongue () le 19/09/2005 à 22:25. (lien). Évalué à 4.Concernant l'utilisation du proc et de la ram, j'aurais quelques mots à dire. J'ai pas une bête de courses m'enfin un bi pIII500 avec 384Mo de ram, je me disais que ca le ferait bien de tester un truc comme ca.
J'y vais de quelques compilations puis je lance la bête, et ca mouline, encore et encore. Au bout d'une heure, je lance une petite recherche boum un plantage de l'interface en gtk. Je me désespère pas, je recommence et là j'arrive à avoir quelque chose. Jusque là, ca marche. Je le laisse tourner tout de go toute la journée, mais pendant que je mettais à jour mon système, je me suis aperçu que beagled+mono me bouffait environ un tiers de ma ram.
Depuis je l'ai viré parce que fondamentalement ca me sert à rien et que pour le moment je considère que C# n'est pas mature. Y a qu'à voir mon expérience avec Muine (encore un truc édifiant), mais c'est une autre histoire.-
[^]Re: y a des progres a faire et faut que je devienne riche
Posté par LeMagicien Garcimore () le 20/09/2005 à 13:48. (lien). Évalué à 4.pour le moment je considère que C# n'est pas mature.
Correction : tu considères que Mono n'est pas mature, C# en est à sa deuxième version et il va bien, merci :)
Et en fait c'est peut êtres les logiciels développés avec qui ne sont pas stables. Mais des soft en C/GTK+ qui plantent, on en trouve aussi...-
[^]Re: y a des progres a faire et faut que je devienne riche
Posté par Gilles Dartiguelongue () le 21/09/2005 à 20:42. (lien). Évalué à 2.certes, mille excuses pour l'assimilation C#/mono, c'est bien de mono que je voulais parler.
Et en fait c'est peut êtres les logiciels développés avec qui ne sont pas stables.
Tout à fait, cependant quand j'entends plusieurs personnes (sérieuses) chanter les louages d'applis qui crashent lamentablement souvent, ca me fait grincer des dents.
-
-
"Machine puissante" pas si nécessaire...
Juste pour préciser le terme un peu vague présent dans la niouze sur la puissance nécessaire en détaillant mon expérience:
Je suis en Unbuntu hoary sur un portable (donc disque et CPU pas top) Dell Precision M60 à 1.6Ghz. De plus je n'ai pas le mode "inotify" dans mon kernel (là pour accélerer le bouzin).
Avec cette config un peu cata (1.6Ghz c'est deja pas mal pour les end-users mais pas genial pour ceux succeptibles d'installer beagle (version plus qu'alpha)), j'utilise donc beagle et ses outils depuis 3 semaines et je n'ai pas observé de ralentissement notable de ma machine à l'utilisation (Desktop, dev leger mais aussi pour des jeux...).
Le truc "c'est nul ça me bouffe mon CPU" ne m'est jamais arrivé...
-
[^]Re: "Machine puissante" pas si nécessaire...
Posté par Matthieu MARC () le 16/09/2005 à 14:50. (lien). Évalué à 3.Moi ça m'est arrivé sur mon portable même config que toi sous ubuntu. J'avais en plus mis le support pour firefox. Et je crois que ce support prenait tellement de ressource que le mieux était de redémarrer.
Le truc "c'est nul ça me bouffe mon CPU" ne m'est jamais arrivé...
Le truc "c'est nul ça m'a bouffé mon CPU quelques fois" m'est arrivé...
-
[^]Re: "Machine puissante" pas si nécessaire...
Posté par Ph Husson (page perso, ) le 16/09/2005 à 16:57. (lien). Évalué à 5.Euh quoi comme processeur?
Si c'est un pentium M c'est une vrai fusée....-
[^]Re: "Machine puissante" pas si nécessaire...
Posté par yoho (page perso, ) le 24/09/2005 à 08:53. (lien). Évalué à 1.Moi, ça me bouffait 100% du cpu, mais le process était en "nice" si bien que toutes mes applis marchaient aussi bien qu'avant (beagle utilise tout simplement moins de CPU si je lance d'autres applis). Bon lancer un tuxracer, je dis pas... mais aucun problème avec le flash sous firefox, par exemple.
-
Plugin firefox
j'ajouterai à la niouze le fait qu'il y ait une extension firefox pour indexer les pages que l'on a browsé :
http://www.beagle-project.org/Firefox_Extension(...)
Conception IHM
Beagle est un bon concept a la base et rempli parfaitement sa tache.
Le seul reproche que j'ai a lui faire est l'interface "Best" mal pensée. Trop peu de resultats sont affichages directement ce qui sous entends de devoir souvent cliquer sur next pour voir la suite. S'ensuit une perte de temps.
Je pense que là ou ca pourrait le faire, ca serait d'integrer beagle avec nautilus (plugin?). Par exemple, une barre de saisi ou tu mettrais ton/tes critere(s) de recherche et ou le resultats s'affiche directement dans ton espace de navigation...
L'utilisateur ne se soucierait plus de son systeme de fichier mais simplement de ses documents.
Comment qui disent déja?! usabilitttty...
-
[^]Re: Conception IHM
Posté par scls19fr (page perso, ) le 16/09/2005 à 16:28. (lien). Évalué à 1.oui ça revient à une idée que j'avais il ya quelques temps... Nautilus everywhere ;-)
Nautilus pour chercher dans la doc, pour chercher dans les fichiers, etc...
On se refait l'explorateur... en mieux ;-)
http://bugzilla.gnome.org/show_bug.cgi?id=306131(...)
dommage pour la fin
All right, there are like a dozen things being discussed in this thread, which
makes this a difficult bug to track and manage. Aside from making Nautilus some
sort of universal help viewer (which, I assure you, will never happen), what is
the proposal in this bug report?
-
[^]Re: Conception IHM
Posté par gnumdk (page perso, ) le 16/09/2005 à 18:03. (lien). Évalué à 6.Ca existe déjà, ca s'appelle beagle kio. Bon, pour ca, faut un environnement un peu moderne avec des technologies qui permettent de coder rapidement un truc ultra efficace :) Y'avait déjà kio-locate qui était génial dès qu'on cherchait un fichier dans n'importe quelle appli kde, un kio:*.ogg dans la barre d'url et hopla, y'a plus qu'a prendre celui qu'on cherche.
http://www.kde-apps.org/content/show.php?content=28437(...)
-
[^]Re: Conception IHM
Posté par Mathieu Pillard (page perso, ) le 23/09/2005 à 09:38. (lien). Évalué à 2.Ca tombe bien, les développeurs de beagle sont bien conscients du fait que best est actuellement plutot limité. Ils organisent un hackfest dont le but est plutot ambitieux. Voir le mockup et les infos ici: http://joeshaw.org/2005/09/22/179(...)
xattr ?
Beagle requiert un système de fichiers possédant xattr :
- qu'est-ce que c'est ? Oo
- quels sont les FS qui le possèdent ?
\_o<~~~~
-
[^]Re: xattr ?
Posté par TImaniac (page perso, ) le 16/09/2005 à 16:42. (lien). Évalué à 6.C'est la possibilité d'ajouter des méta-données aux fichiers, de les "marquer".
Ext3 supporte les xattr, ReiserFS implémente son propre format plutôt que le format standard du noyau Linux, et a donc un support séparé pas encore aussi fonctionnel dans beagle.-
[^]Re: xattr ?
Posté par tgl () le 16/09/2005 à 18:29. (lien). Évalué à 2.J'ajouterais que :
- si tu compiles toi même tes noyaux, alors il faut vérifier que c'est activé, ici : File systems --> Ext3 journalling file system support --> Ext3 extended attributes. (pareil pour ext2 d'ailleurs) ;
- si tu utilises un kernel de distrib, il est extrêmement probable que ce soit déjà activé ;
- dans tous les cas, il faut passer dans ta fstab l'option qui va bien, "user_xattr", pour ta partition /home (ou carrement / si tu n'as pas de /home).
-
-
[+] [^]Re: xattr ?
Posté par herodiade () le 17/09/2005 à 09:48. (lien). Évalué à -4.Ah ça doit être super portable, beagle !
-
[^]Re: xattr ?
Posté par Erwan (page perso, ) le 17/09/2005 à 10:20. (lien). Évalué à 5.oui.
http://users.avafan.com/~fredrik/best-win32.jpg(...)
http://mail.gnome.org/archives/dashboard-hackers/2005-January/msg00(...)
-
Hum....
Personnellement, ce mono m'embête.
En effet, il correspond à la sous-partie "normalisée" de .NET avec des "bindings" pour les technologies du libre. Il ne faut pas prendre les enfants du bon Dieu pour des canards sauvages, .NET est complètement piloté par une certaine entreprise (les parties non normalisées étant plus ou moins vérouillées par les trucs qu'on appelle brevets logiciels me semble-t-il, sachant que cela ne concerne plus l'Europe, mais bon...). Cela me fait penser à JAVA, complètement piloté par SUN... mais j'ai plus confiance en SUN qu'en l'autre, question de feeling. Mais la JAVA Trap vaut bien la .NET Trap.
Personnellement, je me sentirais beaucoup mieux si une telle application avait été développée dans un langage non lié de manière significative à 1 et 1 seule entreprise (python, ruby, C/C++ etc...).
Désolé, pour moi, mono c'est ".Niet"!
-
[^]Re: Hum....
Posté par Yusei () le 16/09/2005 à 16:58. (lien). Évalué à 8.Il y a une différence de taille entre le "piège Java" et le "piège .NET", c'est le fait que Mono existe et est un logiciel libre. Étant donné un programme Java quelconque, il est peu probable qu'on puisse le faire tourner sur une des implémentations libres d'une machine virtuelle Java (sauf si ses développeurs ont fait un effort dans ce sens). Par contre, un programme développé en C# pour Mono peut être exécuté en n'utilisant que des logiciels libres.
Après, il reste le problème des brevets, problème qui dépasse largement Java et .NET, malheureusement.-
[+] [^]Re: Hum....
Posté par briaeros007 () le 16/09/2005 à 17:29. (lien). Évalué à -1.Étant donné un programme Java quelconque, il est peu probable qu'on puisse le faire tourner sur une des implémentations libres d'une machine virtuelle Java (sauf si ses développeurs ont fait un effort dans ce sens).
Certes classpath etc... ne correspondent pas encore a java 1.5
mais 1.1 et 1.2 (comment ca c'est vieux) sont quand meme pas mal implementer.
Et 1.4 aussi.
si le programme s'appuie pas trop sur toutes les api java les plus recules; et fait une interface graphique pas trop "nouveaux trucs" ca devrais passer sans enormement de problème.
et je ferais remarquer que tout le mone a pas encore le jre 1.5 ;)
D'ailleurs classpath recherche des developpeur si ca t'interesse.--
Subete ga wakatta toki…watashi ga anta wo korosu.-
[^]Re: Hum....
Posté par Yusei () le 16/09/2005 à 17:37. (lien). Évalué à 10.D'ailleurs classpath recherche des developpeur si ca t'interesse.
Je ne fais que souligner une différence entre les deux cas évoqués, personnellement je m'en fiche de Java.
En fait, pour être plus précis, un programme développé avec Mono c'est comme un programme développé avec GCJ: peu importe que derrière ce soit C# ou Java, c'est exécutable en n'utilisant que des logiciels libres, donc ça échappe à ce que RMS appelle le "piège Java". Ceux qui prennent le risque de tomber dans le piège sont ceux qui développement avec les outils de dev de Microsoft (pour .NET) ou de Sun (pour Java) et qui pensent pouvoir faire un logiciel entièrement libre de cette manière.
Voilà, formulé comme ça, j'ai moins l'air d'agresser les pauvres développeurs de classpath ?
-
[^]Re: Hum....
Posté par Ph Husson (page perso, ) le 16/09/2005 à 18:38. (lien). Évalué à 4.Et je ferais aussi remarquer que gcjx (donc gcj pour java 1.5) aurait bien besoin de tests :p
/me qui essaye de faire marcher lg3d sur gcjx
-
-
[^]Re: Hum....
Posté par boubou (page perso, ) le 19/09/2005 à 12:11. (lien). Évalué à 6.Cette différence n'existe pas. Si tu développes en Java avec Eclipse et comme cible classpath+gcj (par exemple), ton application ne tournera qu'avec du 100% libre, c'est exactement la même chose que pour Mono. Par contre, si tu récupères une application C#/.NET développée sous windows et utilisant à fond les WinForms, elle ne marchera pas plus qu'une application Swing utilisant les composants manquants de cette bibliothèque dans classpath.
A titre d'information, plus de 92 % de l'API du JDK 1.4 est implémentée par Classpath. Les extensions J2EE 1.4 sont intégralement implémentées par divers projets open source comme JBoss ou Jonas.
Moralité, la situation en pratique est plus ou moins la même pour Mono et Classpath+gcj. Par contre, du point de vue légal, ah, ah, ah...-
[^]Re: Hum....
Posté par Nicolas () le 19/09/2005 à 16:23. (lien). Évalué à 1.et le 1.5 ? Je pose la question c'est pour OpenOffice.org2 qui utilisent des trucs de cette version de java. En aprticulier le media player.
-
[^]Re: Hum....
Posté par boubou (page perso, ) le 20/09/2005 à 16:34. (lien). Évalué à 5.Pour le 1.5, c'est environ 84%. On trouve les couvertures sur le site d'un développeur de kaffé : http://www.kaffe.org/%7Estuart/japi/(...) On se rend compte que le point bloquant reste essentiellement swing. Il y a quelques soucis avec corba et le son, mais en ajoutant d'autres bibliothèques, on couvre presque tout. L'énorme défaut des initiatives Java libre est qu'elles ne disposent pas d'un point d'accès unique et d'un projet centralisateur, au contraire de Mono. Mono n'est pas plus avancé que les outils Java open source, il l'est même moins en terme de compatibilité avec les bibliothèques de MS (n'oublions pas qu'en ajoutant à Java de base les extensions entreprises, on obtient une api monstreuse dont la partie entreprise est entièrement couverte par du libre, donc le pourcentage de couverture grimpe énormément), mais il est centralisé et bien organisé...
-
-
-
Cette discussion est archivée, il n'est plus possible de laisser des commentaires.
Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.