lundi 05 janvier
Accueil :: Dépêches :: Entretiens :: Journaux :: Forums :: Sondages :: Suivi :: Statistiques :: Contact :: Plan

Derniers journaux de patrick_g :

Journal : les nouveautés de KDE 3.4

Posté par patrick_g (page perso, ) le 03 décembre 2004
0
un petit article ( http://osdir.com/Article2722.phtml(...) ) qui liste quelques une des nouveautés de la prochaine release de KDE.

Deux questions pour ceux qui savent :

1) pourquoi la page est en .phtml ? c'est quoi ce truc ?

2) parmi les nouveautés y'a QCA - A complete cryptography architecture : quelqu'un a t'il des renseignements supplémentaires ? pourquoi ne pas utiliser l'API crypto du noyau qui doit être bien mieux testé ?

> Lire le journal (15 commentaires, moyenne: 3,2).  

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.

bout de réponses

Posté par Flink () le 03/12/2004 à 14:49. (lien). Évalué à 5.

Salut !

alors juste pour répondre à ta 2eme question, QCA est une lib de crypto développée à l'origine par les ptits gars de Psi (le client jabber en Qt) et donc intégrée à psi. Ça doit bien faire un an qu'elle existe, et ça marche plutôt bien apparemment. Elle est développée avec Qt ce qui explique sans doute ce choix aussi.

Voilà pour les ptites infos ;)

  • [^]Re: bout de réponses

    Posté par patrick_g (page perso, ) le 03/12/2004 à 15:40. (lien). Évalué à 5.

    merci pour ta réponse.
    je m'y connais pas trop donc je voudrais pas dire de conneries mais ça me semble un peu louche ce projet QCA.
    Dans le monde de la crypto on essaye habituellement d'être le moins compliqué possible pour ne pas augmenter les risques d'erreurs ou de bugs ou de points faibles dans les protocoles...hors QCA ajoute toute une couche QT au dessus d'un noyau linux qui dispose déja d'une API crypto très très complète.
    je ne doute pas que QCA facilite le travail des devs KDE mais il me semble que dans le domaine spécifique de la crypto c'est dangereux.

    • [^]Re: bout de réponses

      Posté par √λιi () le 03/12/2004 à 18:01. (lien). Évalué à 3.

      Oui mais Qt à ausi pout but (et y arrive très à ce qu'il me semble) d'être multi-plates formes. Alors avec la crypto du noyau, tu vas être bien sous windows ou MacOS.

    • [^]Re: bout de réponses

      Posté par cedric () le 04/12/2004 à 17:28. (lien). Évalué à 0.

      au dessus d'un noyau linux


      Euh, je ne savais pas qu'on pouvait acceder a l'API crypto de linux depuis l'userland. Tu aurais des pointeurs la dessus, ca m'interresse.

  • [^]Re: bout de réponses

    Posté par jcs (page perso, ) le 03/12/2004 à 18:55. (lien). Évalué à 4.

    Je me permet aussi d'ajouter que QCA n'est qu'une facade devant des bibliothèques qui font effectivement de la crypto, par exemple libopenSSL ou libNSS.

    En outre j'aurai plutôt tendance à penser qu'il vaut mieux éviter de demander quelque-chose au noyau quand cela peut être fait en userland.

    Enfin, l'API crypto du noyau ne sait pas tout faire entre autre ASN.1, support X.509, pkcs#11, pkcs#12... (bon j'avoue je ne suis pas sûr de ma liste mais l'idée est là)

    --
    Hurd will be out in a year (or two, or next month, who knows)
    -- Linus Benedict Torvalds, 1991

Et pour 1!

Posté par Nicolas (page perso, ) le 03/12/2004 à 14:52. (lien). Évalué à 1.

Pourquoi pas phtml! En général c'est du php!

1/

Posté par Cali_Mero () le 03/12/2004 à 14:53. (lien). Évalué à 3.

.phtml, c'est php.

Mais juste pour info, sur le web les extensions de fichier ne veulent _absolument_ rien dire, ce sont les mimetypes qui comptent. Ne te bute donc pas trop là dessus (essaye de renommer un document html en .gif, tu verras le résultat)

--
#define MAGIC 0xdefaced /* I should've patented this number -cliph */

  • [^]Re: 1/

    Posté par Aurélien Girard () le 03/12/2004 à 15:57. (lien). Évalué à 6.

    J'ajouterais qu'à part sur des systèmes préhistoriques et mal foutus, les extensions ne veulent jamais rien dire.

    D'ailleurs, il serait temps que Linux propose quelquechose de plus complet à ce sujet (les applis "devinent" le type du fichier en le regardant). Il n'y a qu'à voir du coté de BeOS ou de MacOS ou le type MIME du fichier est stocké dans un attribut.

    --
    BeOS le faisait il y a 10 ans.

pourquoi ne pas utiliser l'API crypto du noyau ?

Posté par Aurélien Girard () le 03/12/2004 à 16:00. (lien). Évalué à 7.

Parceque KDE n'est pas l'interface graphique de Linux mais un bureau graphique qui fonctionne sous plusieurs systèmes (Linux, les BSD, sous X, sur un PDA, etc.)

--
BeOS le faisait il y a 10 ans.

  • [^]Re: pourquoi ne pas utiliser l'API crypto du noyau ?

    Posté par patrick_g (page perso, ) le 03/12/2004 à 16:25. (lien). Évalué à 2.

    grummbbll..........effectivement j'y avais pas pensé et ça explique le pourquoi du comment.
    N'empêche que je trouve ça lourdingue et dangereux. j'espère que c'est juste une sorte de wrapper en QT qui s'occupe de l'abstraction des diverses API noyaux sous-jacentes.

    Pour que je dorme sur mes deux oreilles je souhaite _vraiment_ qu'en dessous de toutes ces couches je retrouve l'API crypto de mon kernel.

    • [^]Re: pourquoi ne pas utiliser l'API crypto du noyau ?

      Posté par Philippe Fremy (page perso, ) le 03/12/2004 à 21:13. (lien). Évalué à 3.

      C'est quoi l'api crypto de linux ? Linux permet de generer des cles RSA ? De faire des verifications de signature RSA ? D'encrypters des donnes en triple DES et AES ?

      ==> NON !

      Je ne sais pas de quelle api crypto tu parles, mais clarement, linux ne suffit pas pour coder une application avec de la crypto. Il faut utiliser utiliser une lib qui code tous les algos. En general, on utilise openssl (www.openssl.org) mais rien n'empeche de le re-ecrire.

      --
      phil.freehackers.org

      • [^]Re: pourquoi ne pas utiliser l'API crypto du noyau ?

        Posté par patrick_g (page perso, ) le 07/12/2004 à 08:54. (lien). Évalué à 2.

        ???????????????

        quand tu vois que le dernier kernel 2.6.9 integre un nouvel algo symétrique (anubis) je pense que on peux en déduire que le kernel intègre une lib d'algos optimisés......non ?

Sinon pour les trolleurs:

Posté par Ph Husson () le 03/12/2004 à 16:06. (lien). Évalué à 1.

Merging with Safari fixes continues, alone with new work and fixes by KDE developers.

Sinon en vrac:
- Usage of GCC 3.4 symbol visibility functionality for much improved application startup time.
Il me semblait que c'etait gcc 4.0? (ou 3.4 patché)
Mais bon n'empeche que c'est une bonne idée

KDM theme support.
Deja vu dans un journal précendent mais ca fait plaisir de le rapeller :)

- Empty password support (password-less wallets) in KWallet.
J'espere qu'on poura désactiver ca.....

Support for setting the clock with NTP.
Ca serait pas plutot au niveau de la distrib de faire ca?
Enfin bon ca peut quand meme etre une bonne idée

- Completely redesigned, more flexible trash system.
Mmmmmm à voir, mais personnellement je prefererais qu'ils utilisent recycled4linux 'fin bref

- Support for Apple's DNS based service discovery.
OO? Je croyais que c'etait un zeroconf ?
Remarque d'apres mes souvenirs c'est pas encore supporté par KDE donc c'est juste un nom différent.

- Subversion support.
Que dire à ce propos? :)

  • [^]Re: Sinon pour les trolleurs:

    Posté par patrick_g (page perso, ) le 03/12/2004 à 16:28. (lien). Évalué à 1.

    Quand ils disent merging with safari je suppose qu'ils parlent de KHTML et de rien d'autre ?

    sinon pour ton appel au troll sur Subversion je ne trouve rien d'autre à dire que ARCH POWAAAAAA !!!!!

  • [^]Re: Sinon pour les trolleurs:

    Posté par Julien MOROT (Jabber id, page perso, ) le 03/12/2004 à 17:42. (lien). Évalué à 5.

    - Empty password support (password-less wallets) in KWallet.
    J'espere qu'on poura désactiver ca.....

    En fait ça a été un souhait émis sur le bugzilla de KDE. Il a été codé contre la volonté des développeurs mais a été fait malgré tout face au nombre de votes.

    Support for setting the clock with NTP.
    Ca serait pas plutot au niveau de la distrib de faire ca?
    Enfin bon ca peut quand meme etre une bonne idée
    Gnome 2.8 le fait déjà. Après qu'on utilise ntpdate en service ou une appli graphique de la distrib ou de l'environnement de bureau, les droits root sont de toute façon nécessaires et c'est juste une couche visuelle.

    - Support for Apple's DNS based service discovery.
    OO? Je croyais que c'etait un zeroconf ?
    Zeroconf / DNS-SD / Apple mDNSResponder c'est trois noms pour la même chose en fait :) Genre Firewire, i-Link et IEEE 1394. Il est question d'ailleurs en ce moment même de déplacer kdnssd de kdenonbeta vers kdelibs.

    Sinon la liste des fonctionnalités devant normalement être ajoutées à KDE 3.4 se trouve ici :

    http://developer.kde.org/development-versions/kde-3.4-features.html(...)

Revenir en haut de page

Run by Team LinuxFr.org

Cette page a été générée par Templeet en 0.0805s (dont 0.0083 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
Faire un don !