Oui, des applications de citée. (j'aurais ajouté celle de l'antenne de téléphone moi, c'est la seule qui me parait vraiment intéressante)
En quelles applications : un système de génération de paysage, un truc pour faire une belle image donc, alors que les trois quart du reportage on essais de nous convaincre que justement ça ne sert pas qu'à ça les fractales.
Et une autre de *l'état de la recherche* qui pourrait peut-être permettre d'éventuellement si ça se trouve....
Encore une fois, ce n'est pas l'intérêt de la théorie que je critique, mais la façon dont c'est présenté dans le reportage.
Je le trouve vide, se contentant d'énumérer des choses sans donner aucun argument, c'est de l'habillage complètement creux au niveau sémantique et technique.
Je trouve que les reportages pour la secte richnous sont aussi profonds et convaincants.
Au passage, c'est limite quand même le placement publicitaire pour le 4x4 sur la fin, quand on le voit passer dans une flaque d'eau, genre "on part à l'aventure dans les bois -mais sur un route bien balisée quand même- avec notre super 4x4 qui traverse les torrents", avec les gars qui font leurs écolos juste après genre "on a eu l'autorisation de couper l'arbre, mais c'est parce qu'il est malade!"
C'est pas la coupe d'un arbre dans une foret à des fin d'études qui fou la merde dans la concentration de CO2 de l'atmosphère.
En plus, leur coup du "c'est génial, la structure de la foret est la même que celle de l'arbre, donc ça valide notre théorie et on sait quel est le potentiel d'absorption de CO2 de la foret!"
Je vois pas trop comment ils peuvent valider leur théorie comme ça, sans avoir une mesure du taux d'absorption réel de CO2 de la foret et de la comparer avec leurs calculs. C'est vraiment de la fumisterie ce qu'ils disent à ce moment là...
Sans commenter sur la pertinence et l'intérêt des fractales dans le domaine mathématique, informatique ou biologique. Je trouve ce reportage très moyen.
déjà, l'auteur à un sacré partit pris, aucun argument contre. forcément en ne passant que des témoignages qui trouvent que les fractales, c'est tout bien, bah on donne l'impression que c'est le cas!
Il citer quand même des réfractaires à la théorie, mais de façon très trollesque, en les ringardisant et presque en se moquant d'eux, genre vers le milieu quand il parle de "mathématiciens réfractaires" "attachés à l'ancien paradigm" avec une vieille formule de pythagore au tableau...
Faut pas déconner non plus, je pense qu'il y a quand même dans la communauté mathématique des gens intelligents qui savent évaluer le travail des autres, qui bossent sur autre chose que des triangles rectangles et qui ont peut-être des avis plus nuancés que ça.
aussi, le niveau de vulgarisation est pas loin d'un E=M6, à aucun moment il ne donne une explication sur quoi que ce soit (à part peut-être un peu quand il parle des antennes de téléphone) Il se contente d'énumérer des trucs comme c'est bien et tout ce qu'il est possible d'imginer de pourvoir éventuellement, si la recherche progresse et abouti à quelque chose d'intéressant qui pourrait être exploité dans un domaine utilisable, faire.
Je veux bien que son histoire de mesurer les cotes ça marche pas, il me dit qu'avec des fractales, ça marche. Soit, c'est quoi alors le résultat? Pas un mot...
Les fractales sont certainement un domaine très intéressant, mais ce reportage ne l'est pas, en tous cas, pas pour moi.
Lorsqu'un routeur voit une requête IGMP passer, il mémorise /juste/ :
- l'adresse du flux demandé
- l'interface d'ou la requête provient
- l'heure du dernier (renouvellement de l') abonnement pour ce flux
Ca me semble plus être un détail d'implémentation qu'une spec ce que tu décris là.
Moi si j'avais à l'implémenter (et j'avoue être archi-nul en implémentation de routeurs multicast) je mémoriserai aussi l'ip de la machine qui à fait la requête, pour pouvoir l'effacer de ma table lors d'une requête d'annulation, car si tu te contente de décrémenter les abonnement de flux sans regarder de qui viens la requête, tu peux recevoir plusieurs requêtes de désabonnement d'une même machine ce qui va te causer des problèmes.
Bon, il est aussi possible de remédier à ce problème en ne forwardant pas les requêtes d'annulation si tu n'as pas d'abonnement sur une interface donnée, mais ça requiert quand même un peu d'analyse des paquets, et je suis sur que ça peut induire d'autres problèmes, surtout en cas de perte de paquet et de renvoie de requête, car il me semble que c'est plus proche d'un protocole UDP que TCP ce truc là.
sauf que si quelqu'un me vole ma voiture pour aller rouler à 220 km/h (oui, je rêve un peu là, elle dépasse pas les 150 km/h ma voiture en vrai...) sur l'autoroute quand je suis au boulot, je n'aurai aucun mal à me disculper.
l'impression que j'ai est plutôt qu'ils suivent l'autre extrême.
kde 4.0 est sorti avec trop de nouveautés complètement instables et pas finie, parce qu'ils voulaient à tout prix sortir pour avancer. Ce choix leur a été préjudiciable, même s'il peut être compréhensible.
gnome 3.0 est en train d'être de plus en plus repoussé et les changements sont réduits pour éviter de casser toute forme de compatibilité.
Maintenant, l'avenir nous dira quelle était la meilleur stratégie. Personnellement je pense que celle de gnome est meilleur pour l'image et le marketing et celle de kde meilleur pour l'évolution et l'innovation.
tu peux facilement enlever la partie centrale et/ou déplacer chaque partie comme des "docks" en les plaçant à coté/en dessous des autres.
Donc oui, tu peux revenir à une interface très proche de celle d'amarok 1.4
je ne m'explique pas pourquoi je n'ai pas réussi à trouver cette astuce lors de mes précédentes recherches...
En tout cas, merci à ceux qui ont essayé de me répondre :)
dans la partie développement, valgrind et tout de même un incontournable, j'utilise régulièrement memcheck et de temps en temps callgrind. Ces outils sont d'une puissance et d'une utilité incontestable !
j'utilise autant que possible mplayer en ligne de commande, mais dans les raccourcis claviers, je ne trouve pas la possibilité d'avancer ou de reculer de moins de 10 secondes, un seek de une seconde m'irait très bien, et dans l'idéal un (ou plusieurs) seek configurable serait encore mieux.
si quelqu'un a une astuce pour faire ça, je suis preneur.
Ça dépends quels services te rends ton serveur, moi mon serveur fait entre autre point d'accès wifi, je suis donc bien content d'avoir trouvé une carte PCI avec des pilotes libres :)
Je ne suis pas convaincu par cette histoire de coup de pub et de surf.
À mon avis c'est plutôt pour les intégrateurs de matériel embarqué, genre les "internet"-box, et tous les matos qui arrivent avec android (tablettes, téléviseurs, ...)
Lors de l'appel d'offre, il doit y avoir pas mal de boites qui demandent des pilotes libres, non pas pour des raisons philosophiques, mais pour ne pas avoir à se prendre la tête avec des histoires de licence et de non libération de code.
Alors quand tu perds un, deux, plusieurs contrats parce que tes pilotes sont fermés, et bien tu changes, t'as pas trop le choix pour survivre.
Et tout ça nous ramène bien évidement aux histoires de part de marché de linux (histoire de troller un peu quand même...) Perso, si je n'avais aucun problèmes de pilotes et logiciels absents sous mon OS préféré, que je sois le seul à l'utiliser ne me poserai pas de problèmes particuliers.
Mais je sais que dans la réalité économique, il faut un minimum de retour sur investissement, et pour ça, il faut un minimum de clients réels (et pas potentiels) pour que les choses évoluent dans le bon sens.
mysql peut être utilisé sans lancer de serveur, directement depuis akonadi (ou toute autre appli) avec la libmysql et attaquer un fichier privé comme base de données.
"On pourrait effectivement parler de performances, de cache, mais pour ça, il faudrait que kde4 soit performant."
tu disais te poser cette question "très sérieusement" Que viens faire cette insulte gratuite qui n'apporte rien là dedans ?
1) les performances de kde sont moins bonnes que celles de kde3, mais elles ne sont pas "catastrophiques"
2) les problèmes de performances sur certains problèmes n'empêchent en rien le fait de vouloir les régler sur d'autres.
3) les optimisations de code et d'algo ne suffisent pas toujours à améliorer les performances, on fini par atteindre les limites de ce qui peut être fait à un moment, et si on veut faire mieux, la seule façon est d'essayer une autre voie.
"Et puis, monter une usine à gaz pour charger 300 contacts, je suis pas convaincu. Par contre, stocker chaque mail que je consulte via imap dans une base de données, je suis sûr que ça plombe les perfs."
akonadi, c'est pas pour stocker 300 contacts, je pense que même les développeurs KDE savent que pour ça, on a pas besoin d'un système de gestion des données personnelles centralisées qui utilise un SGBD.
Ensuite, tu as beau être "sûr que ça plombe les perfs" ça reste de la théorie de comptoire, et en matière d'optimisation, il n'y a qu'une seule règle absolue, tester !
Tu vas toujours trouver que dans ton super cas à toi avec 3 mail et 1 date dans ton calendrier, les perfs sont plombées, mais si ça prends 0.003 secondes au lieu de 0.000001 secondes, c'est pas la mort. Par contre, le type qui a vraiment une grosse base de mails, de contacts, de calendriers et tout, il sera content d'avoir un truc plus réactif.
De ton coté, si tu ne peux pas patienter ces 0.002999 secondes supplémentaires, tu peux toujours utilser mutt, il lira et fera des recherches dans tes 1 mail super rapidement et sans plomber aucune perf !
"Non, je crois vraiment qu'aknoadi est l'un des pires choix qu'ait fait kde4. Sur le papier, ça avait l'air joli, dans les faits, ça ne marche pas."
Moi j'appelle ça un bon choix, plombé par des problèmes techniques et des retards d'implémentation.
Je suis le premier frustré de l'avancement d'akonadi, j'aurai aimé (et je pensais, à la sortie de kde 4.0) en être au point actuel dans la version 4.2 de KDE, finalement, c'est beaucoup plus long que prévu, mais les choses avancent, et je ne doute toujours pas des avantages technologique de ce choix par rapport aux autres, comme je ne doutais pas du potentiel de kde 4 avant la sortie de la 4.0, et il n'y a qu'a voir la vitesse à laquelle les développeurs arrivent à faire avancer les choses à chaque version pour s'en convaincre. ça a été long, mais maintenant, chaque version, en plus d'ajouter son lot de régressions, viens avec ses améliorations en terme de performance et consomation, d'ergonomie, de fonctionnalités et de nouveau outils et logiciels.
ok, je me suis peut-être mal exprimé, mais il me semblait en avoir parler. l'intérêt du serveur plutôt qu'une api ou chaque appli attaque les fichiers de config dans son propre process est la gestion des accès concurrents (sur du nfs par exemple, c'est impossible à faire, sur un FS local, ça l'est, mais c'est très compliqué et limité), la gestion plus fine des droits (rien dans akonadi ne permet à l'heure actuelle de faire ça, mais c'est complètement infaisable avec un accès direct aux données depuis les applications) et la gestion de caches et des ressources et leur réutilisation par plusieurs applis (performances améliorées, pas besoin de reparser les fichiers de données et config pour chaque appli, pas besoin de se connecter au serveur imap pour chaque appli)
Pour DBus sur le réseau, il me semble que ça a toujours fonctionné, il y a de sévères limitations (entre autre l'impossibilité d'identifier avec certitude l'id de l'utilisateur faisant la requête, ce qui parait normal, et aussi des problèmes de performance) mais DBus en lui même dialogue par dessus une socket de type unix, qui a strictement (à part pour l'id utilisateur donc) la même api et le même fonctionnement qu'une socket tcp. Et il me semble que le code qui ouvre la socket en TCP au lieu d'UNIX est déjà dans DBus depuis la 1.0
"je ne vois pas le bénéfice d'avoir un *serveur* akonadi par rapport à une API d'accès aux données."
Le fait que ce soit un serveur n'empêche en aucun cas d'avoir une API "à la KDE" pour y accéder. Tu ne fais pas des requêtes toi même sur le réseau via DBus (ou sans...) mais tu utilises libakonadi qui est une abstraction de haut niveau au protocole de communication.
rien n'est fini ni figé, tu peux déjà demander une sauvegarde des informations d'akonadi et les importer sur une autre machine. c'est toujours un bon point.
Ensuite les requêtes vers akonadi sont faites via DBus et seulement lui il me semble, or DBus peut fonctionner sur un réseau, donc il n'y a pas de limitation technique qui empecherait akonadi de tourner sur une machine et des clients de 4 machines différentes d'y accéder. (il faut bien sur que les clients puissent faire une connexion DBus réseau et que akonadi écoute le réseau pour des requêtes DBus, ce qui n'est pas le cas actuellement)
En tant qu'utilisateur, un des intérêts est d'avoir tes infos centralisées quel que soit le logiciel que tu utilises, tu n'as toujours qu'un seul endroit à changer, à configurer, à mettre à jour pour que tous les logiciels qui ont besoin de cette info l'aient à disposition.
En tant que développeur, tu n'as pas à coder la partie base de données et requêtes sur les informations, en plus tu n'as aucun problème d'accès concurrent aux fichiers de ressources qu'il est très difficile de résoudre en bossant appli par appli. Tu peux écrire une appli qui vérifie si tu as de nouveau mails et t'affiche le sujet, un lien vers d'éventuelles pièces jointes et un lien vers le contact de messagerie instantané correspondant à l'envoyeur s'il est connecté; le tout très rapidement et avec très peu de code.
"mon pc fixe à la maison est un pentium II 266MHz, avec 600 Mo de RAM."
l'objectif de KDE est, entre autre, de proposer un environnement de bureau avec une suite logicielle cohérente, aux fonctionnalités avancées et fonctionnant sur du matériel résonnablement moderne.
L'objectif était le même avec kde3, sauf qu'à l'époque, ton matos était raisonnablement moderne, ce n'est plus le cas aujourd'hui.
Je pense que demander comme matériel raisonnablement moderne une machine de moins de 6 ans n'est pas abusif, surtout que ce n'est pas le seul environnement de bureau libre et qu'ils n'ont pas sur les épaule le fardeau d'avoir à combler les besoins et envies en terme d'environnement de travail de tous les utilisateurs de logiciels libres.
beaucoup de bonnes idées de Decibel on été reprises par l'implementation actuelle de téléphaty.
les dev de kopete souhaitent migrer vers télépathy, mais manque de dev, de temps, toussa...
akonadi ne stocke pas que les mail, il stocke toutes tes info perso (mail, vcard, calendrier, contact, ...) ET les meta données associées (et les tags qui tu as pu placer dessus)
Et ensuite, il ne sert pas qu'à les fournir à kmail, mais ou tout autre client pim à qui tu en autorise l'accès.
Ça permet d'avoir une base de données centralisée (et non redondante entre applis) de tes infos personnelles avec une interface d'accès uniforme et concurrente (ça se dit ça ?)
[^] # Re: conférence sous-titrée
Posté par moi1392 . En réponse au journal Benoît Mandelbrot change de dimension. Évalué à 1.
http://www.dailymotion.com/video/x1w1r0_les-langages-hermeti(...)
il y en a au moins deux de citées
Oui, des applications de citée. (j'aurais ajouté celle de l'antenne de téléphone moi, c'est la seule qui me parait vraiment intéressante)
En quelles applications : un système de génération de paysage, un truc pour faire une belle image donc, alors que les trois quart du reportage on essais de nous convaincre que justement ça ne sert pas qu'à ça les fractales.
Et une autre de *l'état de la recherche* qui pourrait peut-être permettre d'éventuellement si ça se trouve....
Encore une fois, ce n'est pas l'intérêt de la théorie que je critique, mais la façon dont c'est présenté dans le reportage.
Je le trouve vide, se contentant d'énumérer des choses sans donner aucun argument, c'est de l'habillage complètement creux au niveau sémantique et technique.
Je trouve que les reportages pour la secte richnous sont aussi profonds et convaincants.
Au passage, c'est limite quand même le placement publicitaire pour le 4x4 sur la fin, quand on le voit passer dans une flaque d'eau, genre "on part à l'aventure dans les bois -mais sur un route bien balisée quand même- avec notre super 4x4 qui traverse les torrents", avec les gars qui font leurs écolos juste après genre "on a eu l'autorisation de couper l'arbre, mais c'est parce qu'il est malade!"
C'est pas la coupe d'un arbre dans une foret à des fin d'études qui fou la merde dans la concentration de CO2 de l'atmosphère.
En plus, leur coup du "c'est génial, la structure de la foret est la même que celle de l'arbre, donc ça valide notre théorie et on sait quel est le potentiel d'absorption de CO2 de la foret!"
Je vois pas trop comment ils peuvent valider leur théorie comme ça, sans avoir une mesure du taux d'absorption réel de CO2 de la foret et de la comparer avec leurs calculs. C'est vraiment de la fumisterie ce qu'ils disent à ce moment là...
[^] # Re: conférence sous-titrée
Posté par moi1392 . En réponse au journal Benoît Mandelbrot change de dimension. Évalué à 5.
déjà, l'auteur à un sacré partit pris, aucun argument contre. forcément en ne passant que des témoignages qui trouvent que les fractales, c'est tout bien, bah on donne l'impression que c'est le cas!
Il citer quand même des réfractaires à la théorie, mais de façon très trollesque, en les ringardisant et presque en se moquant d'eux, genre vers le milieu quand il parle de "mathématiciens réfractaires" "attachés à l'ancien paradigm" avec une vieille formule de pythagore au tableau...
Faut pas déconner non plus, je pense qu'il y a quand même dans la communauté mathématique des gens intelligents qui savent évaluer le travail des autres, qui bossent sur autre chose que des triangles rectangles et qui ont peut-être des avis plus nuancés que ça.
aussi, le niveau de vulgarisation est pas loin d'un E=M6, à aucun moment il ne donne une explication sur quoi que ce soit (à part peut-être un peu quand il parle des antennes de téléphone) Il se contente d'énumérer des trucs comme c'est bien et tout ce qu'il est possible d'imginer de pourvoir éventuellement, si la recherche progresse et abouti à quelque chose d'intéressant qui pourrait être exploité dans un domaine utilisable, faire.
Je veux bien que son histoire de mesurer les cotes ça marche pas, il me dit qu'avec des fractales, ça marche. Soit, c'est quoi alors le résultat? Pas un mot...
Les fractales sont certainement un domaine très intéressant, mais ce reportage ne l'est pas, en tous cas, pas pour moi.
# Sonder quand changer
Posté par moi1392 . En réponse au sondage Le sondage sur LinuxFr doit être changé.... Évalué à 10.
[^] # Re: Matlab sans h
Posté par moi1392 . En réponse au journal Faites du gratuit, débrouillez-vous !. Évalué à 10.
Ça c'est de l'oxymore ou je ne m'y connais plus!
[^] # Re: Chapi-Chapo
Posté par moi1392 . En réponse au journal Définition d'une adresse IP par l'hadopi. Évalué à 0.
- l'adresse du flux demandé
- l'interface d'ou la requête provient
- l'heure du dernier (renouvellement de l') abonnement pour ce flux
Ca me semble plus être un détail d'implémentation qu'une spec ce que tu décris là.
Moi si j'avais à l'implémenter (et j'avoue être archi-nul en implémentation de routeurs multicast) je mémoriserai aussi l'ip de la machine qui à fait la requête, pour pouvoir l'effacer de ma table lors d'une requête d'annulation, car si tu te contente de décrémenter les abonnement de flux sans regarder de qui viens la requête, tu peux recevoir plusieurs requêtes de désabonnement d'une même machine ce qui va te causer des problèmes.
Bon, il est aussi possible de remédier à ce problème en ne forwardant pas les requêtes d'annulation si tu n'as pas d'abonnement sur une interface donnée, mais ça requiert quand même un peu d'analyse des paquets, et je suis sur que ça peut induire d'autres problèmes, surtout en cas de perte de paquet et de renvoie de requête, car il me semble que c'est plus proche d'un protocole UDP que TCP ce truc là.
[^] # Re: Chapi-Chapo
Posté par moi1392 . En réponse au journal Définition d'une adresse IP par l'hadopi. Évalué à 5.
[^] # Re: Roooh...zut
Posté par moi1392 . En réponse au journal Il parait que GNOME 2.32 is out. Évalué à 2.
[^] # Re: Roooh...zut
Posté par moi1392 . En réponse au journal Il parait que GNOME 2.32 is out. Évalué à 10.
kde 4.0 est sorti avec trop de nouveautés complètement instables et pas finie, parce qu'ils voulaient à tout prix sortir pour avancer. Ce choix leur a été préjudiciable, même s'il peut être compréhensible.
gnome 3.0 est en train d'être de plus en plus repoussé et les changements sont réduits pour éviter de casser toute forme de compatibilité.
Maintenant, l'avenir nous dira quelle était la meilleur stratégie. Personnellement je pense que celle de gnome est meilleur pour l'image et le marketing et celle de kde meilleur pour l'évolution et l'innovation.
[^] # Re: whaou
Posté par moi1392 . En réponse au journal Softs qui déchiraizent \o/. Évalué à 3.
-----> []
[^] # Re: whaou
Posté par moi1392 . En réponse au journal Softs qui déchiraizent \o/. Évalué à 3.
Donc oui, tu peux revenir à une interface très proche de celle d'amarok 1.4
http://www.youtube.com/watch?v=lpx4jwt1ILE&feature=relat(...)
[^] # Re: Difficile de choisir
Posté par moi1392 . En réponse au journal Softs qui déchiraizent \o/. Évalué à 2.
je ne m'explique pas pourquoi je n'ai pas réussi à trouver cette astuce lors de mes précédentes recherches...
En tout cas, merci à ceux qui ont essayé de me répondre :)
[^] # Re: whaou
Posté par moi1392 . En réponse au journal Softs qui déchiraizent \o/. Évalué à 2.
une revue de code est en cours pour réintroduire le tag automatique à partir de l'emprunte d'un fichier musical et de la base de données musicbrainz : http://lists.kde.org/?l=amarok-devel&m=128513412531540&a(...)
[^] # Re: Softs qui déchiraizent \o/
Posté par moi1392 . En réponse au journal Softs qui déchiraizent \o/. Évalué à 5.
[^] # Re: Difficile de choisir
Posté par moi1392 . En réponse au journal Softs qui déchiraizent \o/. Évalué à 1.
si quelqu'un a une astuce pour faire ça, je suis preneur.
[^] # Re: LLVM
Posté par moi1392 . En réponse au journal L'ouverture selon Apple : surtout du marketing. Évalué à 0.
[^] # Re: Correction
Posté par moi1392 . En réponse au journal Broadcom libère ses pilotes. Évalué à 3.
[^] # Re: Joli !
Posté par moi1392 . En réponse au journal Broadcom libère ses pilotes. Évalué à 2.
À mon avis c'est plutôt pour les intégrateurs de matériel embarqué, genre les "internet"-box, et tous les matos qui arrivent avec android (tablettes, téléviseurs, ...)
Lors de l'appel d'offre, il doit y avoir pas mal de boites qui demandent des pilotes libres, non pas pour des raisons philosophiques, mais pour ne pas avoir à se prendre la tête avec des histoires de licence et de non libération de code.
Alors quand tu perds un, deux, plusieurs contrats parce que tes pilotes sont fermés, et bien tu changes, t'as pas trop le choix pour survivre.
Et tout ça nous ramène bien évidement aux histoires de part de marché de linux (histoire de troller un peu quand même...) Perso, si je n'avais aucun problèmes de pilotes et logiciels absents sous mon OS préféré, que je sois le seul à l'utiliser ne me poserai pas de problèmes particuliers.
Mais je sais que dans la réalité économique, il faut un minimum de retour sur investissement, et pour ça, il faut un minimum de clients réels (et pas potentiels) pour que les choses évoluent dans le bon sens.
[^] # Re: Différences et similitudes
Posté par moi1392 . En réponse au journal Où l'on trolle sur la médaille Fields.. Évalué à 2.
moi, avec la même expérience que toi, ma conclusion est bien différente : 3.
[^] # Re: kdepim non inclu
Posté par moi1392 . En réponse à la dépêche Sortie de KDE 4.5. Évalué à 3.
"On pourrait effectivement parler de performances, de cache, mais pour ça, il faudrait que kde4 soit performant."
tu disais te poser cette question "très sérieusement" Que viens faire cette insulte gratuite qui n'apporte rien là dedans ?
1) les performances de kde sont moins bonnes que celles de kde3, mais elles ne sont pas "catastrophiques"
2) les problèmes de performances sur certains problèmes n'empêchent en rien le fait de vouloir les régler sur d'autres.
3) les optimisations de code et d'algo ne suffisent pas toujours à améliorer les performances, on fini par atteindre les limites de ce qui peut être fait à un moment, et si on veut faire mieux, la seule façon est d'essayer une autre voie.
"Et puis, monter une usine à gaz pour charger 300 contacts, je suis pas convaincu. Par contre, stocker chaque mail que je consulte via imap dans une base de données, je suis sûr que ça plombe les perfs."
akonadi, c'est pas pour stocker 300 contacts, je pense que même les développeurs KDE savent que pour ça, on a pas besoin d'un système de gestion des données personnelles centralisées qui utilise un SGBD.
Ensuite, tu as beau être "sûr que ça plombe les perfs" ça reste de la théorie de comptoire, et en matière d'optimisation, il n'y a qu'une seule règle absolue, tester !
Tu vas toujours trouver que dans ton super cas à toi avec 3 mail et 1 date dans ton calendrier, les perfs sont plombées, mais si ça prends 0.003 secondes au lieu de 0.000001 secondes, c'est pas la mort. Par contre, le type qui a vraiment une grosse base de mails, de contacts, de calendriers et tout, il sera content d'avoir un truc plus réactif.
De ton coté, si tu ne peux pas patienter ces 0.002999 secondes supplémentaires, tu peux toujours utilser mutt, il lira et fera des recherches dans tes 1 mail super rapidement et sans plomber aucune perf !
"Non, je crois vraiment qu'aknoadi est l'un des pires choix qu'ait fait kde4. Sur le papier, ça avait l'air joli, dans les faits, ça ne marche pas."
Moi j'appelle ça un bon choix, plombé par des problèmes techniques et des retards d'implémentation.
Je suis le premier frustré de l'avancement d'akonadi, j'aurai aimé (et je pensais, à la sortie de kde 4.0) en être au point actuel dans la version 4.2 de KDE, finalement, c'est beaucoup plus long que prévu, mais les choses avancent, et je ne doute toujours pas des avantages technologique de ce choix par rapport aux autres, comme je ne doutais pas du potentiel de kde 4 avant la sortie de la 4.0, et il n'y a qu'a voir la vitesse à laquelle les développeurs arrivent à faire avancer les choses à chaque version pour s'en convaincre. ça a été long, mais maintenant, chaque version, en plus d'ajouter son lot de régressions, viens avec ses améliorations en terme de performance et consomation, d'ergonomie, de fonctionnalités et de nouveau outils et logiciels.
[^] # Re: kdepim non inclu
Posté par moi1392 . En réponse à la dépêche Sortie de KDE 4.5. Évalué à 1.
Pour DBus sur le réseau, il me semble que ça a toujours fonctionné, il y a de sévères limitations (entre autre l'impossibilité d'identifier avec certitude l'id de l'utilisateur faisant la requête, ce qui parait normal, et aussi des problèmes de performance) mais DBus en lui même dialogue par dessus une socket de type unix, qui a strictement (à part pour l'id utilisateur donc) la même api et le même fonctionnement qu'une socket tcp. Et il me semble que le code qui ouvre la socket en TCP au lieu d'UNIX est déjà dans DBus depuis la 1.0
[^] # Re: kdepim non inclu
Posté par moi1392 . En réponse à la dépêche Sortie de KDE 4.5. Évalué à 1.
"je ne vois pas le bénéfice d'avoir un *serveur* akonadi par rapport à une API d'accès aux données."
Le fait que ce soit un serveur n'empêche en aucun cas d'avoir une API "à la KDE" pour y accéder. Tu ne fais pas des requêtes toi même sur le réseau via DBus (ou sans...) mais tu utilises libakonadi qui est une abstraction de haut niveau au protocole de communication.
[^] # Re: kdepim non inclu
Posté par moi1392 . En réponse à la dépêche Sortie de KDE 4.5. Évalué à 2.
Ensuite les requêtes vers akonadi sont faites via DBus et seulement lui il me semble, or DBus peut fonctionner sur un réseau, donc il n'y a pas de limitation technique qui empecherait akonadi de tourner sur une machine et des clients de 4 machines différentes d'y accéder. (il faut bien sur que les clients puissent faire une connexion DBus réseau et que akonadi écoute le réseau pour des requêtes DBus, ce qui n'est pas le cas actuellement)
En tant qu'utilisateur, un des intérêts est d'avoir tes infos centralisées quel que soit le logiciel que tu utilises, tu n'as toujours qu'un seul endroit à changer, à configurer, à mettre à jour pour que tous les logiciels qui ont besoin de cette info l'aient à disposition.
En tant que développeur, tu n'as pas à coder la partie base de données et requêtes sur les informations, en plus tu n'as aucun problème d'accès concurrent aux fichiers de ressources qu'il est très difficile de résoudre en bossant appli par appli. Tu peux écrire une appli qui vérifie si tu as de nouveau mails et t'affiche le sujet, un lien vers d'éventuelles pièces jointes et un lien vers le contact de messagerie instantané correspondant à l'envoyeur s'il est connecté; le tout très rapidement et avec très peu de code.
[^] # Re: kdepim non inclu
Posté par moi1392 . En réponse à la dépêche Sortie de KDE 4.5. Évalué à 4.
l'objectif de KDE est, entre autre, de proposer un environnement de bureau avec une suite logicielle cohérente, aux fonctionnalités avancées et fonctionnant sur du matériel résonnablement moderne.
L'objectif était le même avec kde3, sauf qu'à l'époque, ton matos était raisonnablement moderne, ce n'est plus le cas aujourd'hui.
Je pense que demander comme matériel raisonnablement moderne une machine de moins de 6 ans n'est pas abusif, surtout que ce n'est pas le seul environnement de bureau libre et qu'ils n'ont pas sur les épaule le fardeau d'avoir à combler les besoins et envies en terme d'environnement de travail de tous les utilisateurs de logiciels libres.
[^] # Re: Vers où va KDE ?
Posté par moi1392 . En réponse à la dépêche Sortie de KDE 4.5. Évalué à 2.
les dev de kopete souhaitent migrer vers télépathy, mais manque de dev, de temps, toussa...
[^] # Re: kdepim non inclu
Posté par moi1392 . En réponse à la dépêche Sortie de KDE 4.5. Évalué à 4.
Et ensuite, il ne sert pas qu'à les fournir à kmail, mais ou tout autre client pim à qui tu en autorise l'accès.
Ça permet d'avoir une base de données centralisée (et non redondante entre applis) de tes infos personnelles avec une interface d'accès uniforme et concurrente (ça se dit ça ?)