moi1392 a écrit 740 commentaires

un bon fork from scratch

Ça c'est de l'oxymore ou je ne m'y connais plus!

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.

je suis assez d'accord avec ce que tu dis, je ne vois juste pas en quoi cela rends moi exact ce que j'ai dit moi plus haut...

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.

ben quoi, t'empruntes jamais de fichier musicaux toi ??

-----> []

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

http://www.youtube.com/watch?v=lpx4jwt1ILE&feature=relat(...)

la réponse à mon problème est ici : http://www.mplayerhq.hu/DOCS/HTML/fr/control.html

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 :)

Pour moi, la principale feature perdu est la reconnaissance de tag automatique.

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(...)

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.

Pour les licences de type BSD, je dirais plutôt liberté du code, et pas liberté du codeur.

Ç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.

"Expérimentalement, je dirais e"

moi, avec la même expérience que toi, ma conclusion est bien différente : 3.

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

j'ai oublié de répondre à ce point :

"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 ?)

ou alors Domain Name Fyftem, avec un feveu fur la langue !

il y a besoin d'un moyen de stocker et de récupérer des infos sur le disque pour un client mail.
Les développeurs de kmail (ou plutôt d'akonadi) ont décidé (à tord ou à raison, ça peut se discuter) que les concepteurs et développeurs d'un SGBD sont mieux placés pour fournir une solution plus efficace pour stocker et gérer les mails et informations associés sur disque que des développeurs de logiciels quelconques.
Maintenant je ne vois pas en quoi le fait que kmail ait besoin de mysql le rende moins bien, tu ne sais absolument pas ce que mysql rempli comme besoins dans kmail, il pourrait très bien remplacer du code qui était plus volumineux, moins performant et plus bogué mais directement inclus dans kmail, et du coup tu ne t'en rendais pas compte.

Teste le toi même et vois la différence, et après tu pourras venir te plaindre chiffres et expérience personnelle à l'appuis de ce qui ne te conviens pas.

PS: actuellement, au niveau des performances c'est effectivement moins bon qu'en 4.4, mais mysql ne semble pas être le fautif, et j'ai vu plusieurs mail des développeurs qui en parlaient et qui annoncent qu'ils vont bosser pour améliorer ça.

le portage de kmail à akonadi a en effet été reporté jusqu'à cette version. Principalement pour laisser le temps à akonadi de mûrir un peu plus en terme de stabilité et performances et de compléter les fonctionnalités qui lui manquaient. Le travail a été plus important que prévu, et comme souvent, le manque de développeur à fait que cela a été beaucoup plus long que prévu.

Le portage en lui même à finalement commencé un peu avant la sortie de kde 4.4 mais n'est pas complet/fonctionnel/utilisable à ce jour. Donc l'équipe kdepim à décidé de ne pas inclure kdepim 4.5 avec kde sc 4.5

C'est vrai que c'est dommage que ce soit si long, surtout que pour la première version, à mon avis, on se rendra surtout compte des régressions en terme de fonctionnalité, d'ergonomie et de performances par rapport à la version sans akonadi, et ça va râler.
Mais je pense que l'architecture globale de akonadi est un pas dans la bonne direction et qu'une fois bien stabilisé, le développement pourra reprendre de plus belle pour corriger les lacunes et améliorer des tas de choses qu'il était très difficile de faire avant :)