Ç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 ?)
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 :)
pour compléter l'info sur kontact non présent dans kde 4.5, c'est en fait tout kdepim qui n'a pas été inclu.
La raison principale est le portage de kmail vers akonadi, qui est à l'heure actuelle encore assez expérimental (j'en ai une version compilée depuis les sources, et même pour juste rapporter des bugs, c'est très limite)
D'après l'avis personnel que je me fait de cette version, je serais assez surpris si une version stable de kmail 2 sortait avant kde 4.6
Mais en tout cas pour l'instant, la suite kdepim de kde 4.4 est parfaitement utilisable, et elle a même reçu quelques corrections de bogues.
"Il suffit donc de calibrer la taille de la clé pour que le temps nécessaire à la casser soit supérieur à sa durée de vie."
À noter une particularité intéressante, c'est que le temps d'exécution de ton programme de cassage de clé est majoré par une fonction exponentielle, ce qui ne veut pas dire que le temps total d'exécution pour trouver une solution le sera.
Si la bonne clé est la première testée par ton programme (par exemple, si le mot de passe est "password" et que tu le testes en premier, au pif...), elle est trouvée immédiatement ;)
"La seule technique actuelle qui permet d'avoir des effets réalistes, notamment au niveau de la lumière, c'est le raytracing, ce que fait Blender, et ce qui est totalement contraire au concept de vectoriel."
Il a y aussi l'éclairage par radiosité qui est l'exact opposé du raytracing. (avec ses avantages et inconvénients)
j'ai une question, une vrai.
Je n'ai pas particulièrement flash, déjà pour ses problèmes de performance et de non intégration à mon système.
Ensuite pour ses spécifications fermées (c'est toujours le cas au fait ?) et le fait que ce soit un gros binaire.
Enfin et surtout, pour l'utilisation quasi systématique pour la navigation sur des sites.
Par contre, je vois très souvent des gens parler de problèmes de failles de sécurités dans flash, et même si une rapide recherche sur un moteur quelconque me donne pas mal de résultat, j'ai l'impression d'en entendre beaucoup moins que des failles directement dans les navigateurs. En plus je ne connais pas le temps de réaction de la boite qui fait flash sur ces problèmes (il a de fortes chances d'être bien plus long qu'avec un logiciel libre à cause de problèmes de certification et de déploiement, mais je ne sais honnêtement pas ce qu'il vaut)
Alors si c'est autant un problème que ça, pourquoi je ne vois jamais de journaux dessus alors que j'en vois régulièrement sur ie et firefox par exemple (vous pouvez toujours me dire, "t'as qu'à les écrire les journaux")
Tous les logiciels ont des failles, flash est-il un élève particulièrement mauvais dans ce domaine ?
personnellement, je lis plus attentivement les parties qui m'intéressent plus et je survole le reste. en gros je dirais que j'ai lu les 2/3 de l'article et que j'en ai survolé 1/3 (hors interview)
La longueur en elle même ne me dérange pas, surtout que pour d'autres lecteurs, les parties intéressantes ne sont pas les mêmes, donc je pense que tout l'article à sa place ici.
Ensuite, pour l'interview, je l'ai lu et appréciée, mais je pense qu'elle aurait plus eu sa place dans une autre dépêche.
voilà, c'était mes retours et suggestions à deux balles ;)
aaron seigo a posté sur son blog les l'état du développement de plasma.
mais kde c'est bien plus que plasma, kde c'est un environnement de bureau, dont fait partie plasma, mais aussi kwin, et quelques applications de base.
Mais c'est aussi tout un écosystème d'applications cohérentes (entre elles) basées sur les kdelibs, comme digikam, amarok, koffice, kdevelop, et bien d'autres.
le serveur, c'est "xserver" et il là prochaine version est bien la 1.7 (qui devrait sortie à la fin du mois... normalement...)
Xorg, c'est xserver plus tout un tas d'outils et de libs qui vont avec et qui font que tu as sur une machine un serveur graphique fonctionnel et des clients qui peuvent s'y connecter.
La prochaine version de Xorg est la 7.5, car depuis la modularisation avec Xorg 7.0, xserver et les autres modules peuvent avoir des sorties désynchronisées (il y en a eu 2 pour xserver par exemple, la 1.3 et la 1.6)
[^] # 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 ?)
[^] # Re: OMG !
Posté par moi1392 . En réponse au journal ID Software libère Wolfenstein Enemy territory et Return to Castle Wolfenstein. Évalué à 5.
[^] # Re: kdepim non inclu
Posté par moi1392 . En réponse à la dépêche Sortie de KDE 4.5. Évalué à 10.
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.
[^] # Re: kdepim non inclu
Posté par moi1392 . En réponse à la dépêche Sortie de KDE 4.5. Évalué à 4.
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 :)
# kdepim non inclu
Posté par moi1392 . En réponse à la dépêche Sortie de KDE 4.5. Évalué à 2.
La raison principale est le portage de kmail vers akonadi, qui est à l'heure actuelle encore assez expérimental (j'en ai une version compilée depuis les sources, et même pour juste rapporter des bugs, c'est très limite)
D'après l'avis personnel que je me fait de cette version, je serais assez surpris si une version stable de kmail 2 sortait avant kde 4.6
Mais en tout cas pour l'instant, la suite kdepim de kde 4.4 est parfaitement utilisable, et elle a même reçu quelques corrections de bogues.
[^] # Re: Mais ké kidi?
Posté par moi1392 . En réponse au journal P != NP : la preuve. Évalué à 4.
À noter une particularité intéressante, c'est que le temps d'exécution de ton programme de cassage de clé est majoré par une fonction exponentielle, ce qui ne veut pas dire que le temps total d'exécution pour trouver une solution le sera.
Si la bonne clé est la première testée par ton programme (par exemple, si le mot de passe est "password" et que tu le testes en premier, au pif...), elle est trouvée immédiatement ;)
# Affaire SCO : Novell gagne...
Posté par moi1392 . En réponse à la dépêche Affaire SCO : Novell gagne. Évalué à 3.
ça me rappelle un certain "charles" cette histoire...
[^] # Re: Coquilles
Posté par moi1392 . En réponse à la dépêche Nouvelle version 2.6.34 du noyau Linux. Évalué à 2.
"tu nous l'aS demandé"
[^] # Re: C'est moche
Posté par moi1392 . En réponse au journal Google: Que pasa ?. Évalué à 4.
tu vas tout de suite t'en rendre compte
[^] # Re: C'est moche
Posté par moi1392 . En réponse au journal Google: Que pasa ?. Évalué à 4.
Et je suppose que pour les utilisateurs des autres environnements de bureau, c'est à peu près la même chose.
[^] # Re: Non
Posté par moi1392 . En réponse au journal Des films en vectoriel ?. Évalué à 2.
Il a y aussi l'éclairage par radiosité qui est l'exact opposé du raytracing. (avec ses avantages et inconvénients)
[http://en.wikipedia.org/wiki/Radiosity_%283D_computer_graphi(...)]
À noter que blender propose également de faire de l'éclairage par radiosité :
[http://www.archilinux.org/blender-didactic/blender/blender7.(...)]
[^] # Re: Osef
Posté par moi1392 . En réponse au journal IE 8 certifié. Évalué à 3.
Je n'ai pas particulièrement flash, déjà pour ses problèmes de performance et de non intégration à mon système.
Ensuite pour ses spécifications fermées (c'est toujours le cas au fait ?) et le fait que ce soit un gros binaire.
Enfin et surtout, pour l'utilisation quasi systématique pour la navigation sur des sites.
Par contre, je vois très souvent des gens parler de problèmes de failles de sécurités dans flash, et même si une rapide recherche sur un moteur quelconque me donne pas mal de résultat, j'ai l'impression d'en entendre beaucoup moins que des failles directement dans les navigateurs. En plus je ne connais pas le temps de réaction de la boite qui fait flash sur ces problèmes (il a de fortes chances d'être bien plus long qu'avec un logiciel libre à cause de problèmes de certification et de déploiement, mais je ne sais honnêtement pas ce qu'il vaut)
Alors si c'est autant un problème que ça, pourquoi je ne vois jamais de journaux dessus alors que j'en vois régulièrement sur ie et firefox par exemple (vous pouvez toujours me dire, "t'as qu'à les écrire les journaux")
Tous les logiciels ont des failles, flash est-il un élève particulièrement mauvais dans ce domaine ?
[^] # Re: Questions aux lecteurs
Posté par moi1392 . En réponse à la dépêche Nouvelle version 2.6.33 du noyau Linux. Évalué à 3.
La longueur en elle même ne me dérange pas, surtout que pour d'autres lecteurs, les parties intéressantes ne sont pas les mêmes, donc je pense que tout l'article à sa place ici.
Ensuite, pour l'interview, je l'ai lu et appréciée, mais je pense qu'elle aurait plus eu sa place dans une autre dépêche.
voilà, c'était mes retours et suggestions à deux balles ;)
# Linux 3.0 ?
Posté par moi1392 . En réponse au journal WireShark la capture réseau. Évalué à 7.
Rien à dire, ça marche bien chez moi. Pourtant, y'a comme un truc qui me pique les yeux dans cette phrase...
# plasma != kde !
Posté par moi1392 . En réponse au journal Kde 4.4: Où en est on?. Évalué à 10.
mais kde c'est bien plus que plasma, kde c'est un environnement de bureau, dont fait partie plasma, mais aussi kwin, et quelques applications de base.
Mais c'est aussi tout un écosystème d'applications cohérentes (entre elles) basées sur les kdelibs, comme digikam, amarok, koffice, kdevelop, et bien d'autres.
[^] # Re: radeon KMS
Posté par moi1392 . En réponse à la dépêche Nouvelle version 2.6.31 du noyau Linux. Évalué à 1.
Xorg, c'est xserver plus tout un tas d'outils et de libs qui vont avec et qui font que tu as sur une machine un serveur graphique fonctionnel et des clients qui peuvent s'y connecter.
La prochaine version de Xorg est la 7.5, car depuis la modularisation avec Xorg 7.0, xserver et les autres modules peuvent avoir des sorties désynchronisées (il y en a eu 2 pour xserver par exemple, la 1.3 et la 1.6)