Eet passe en 1.0 alpha

Posté par  . Modéré par Mouns.
Étiquettes :
0
2
avr.
2008
Serveurs d’affichage
Rasterman, le project leader d'Enlightenment, vient d'annoncer le passage au stade alpha de la bibliothèque Eet.

Cette bibliothèque, faisant partie des EFL[0] est dédiée à l'encodage/décodage et au stockage des données. Elle est écrite afin d'être très simple pour le programmeur, déchargeant une bonne partie des routines de lecture et d'écriture.

Elle peut par exemple stocker de multiples bouts de données dans un ficher unique à accès arbitraire et rapide, encoder ou décoder des images ou tout autre type de donnée. Les fichiers ainsi produits sont compacts et rapides d'accès tout en étant portable entre différentes architectures (exemple : il est possible de produire un fichier écrit sur une architecture 32bits x86 puis de l'utiliser sur une architecture 64bits PowerPC sans autre action que celle de le déplacer).

Eet est portable sur beaucoup d'architectures et de systèmes d'exploitation (actuellement porté sur GNU/Linux, *BSD et même windows grâce au travail de Vincent Torri entres autres) et fonctionne pleinement sur les systèmes embarqués comme sur les fermes de serveur multi core/CPU.

Au final, Eet est une petite bibliothèque (52Kb sur x86-32, 56Kb sur ARM4) qui soulage le parsage de configuration et gère efficacement aussi bien le stockage que le déplacement des données sans pertes.

Pour finir, Eet n'est pas gourmand en dépendances. Sur les systèmes Unix, mis à part la classique libc et les outils de compilations, ne sont nécessaires que les deux bibliothèques libjpeg et zlib (et leurs version de développement, headers...).

Bien qu'au stade alpha, Eet fait preuve d'une grande stabilité et la version finale 1.0.0 sera publiée lorsque suffisament de monde l'aura compilé, testé, éprouvé. Autrement dit, plus il y aura de poisson, plus vite e17 sortira !

[0] : Les EFL sont les bibliothèques sur lesquelles s'appuie le prochain desktop shell enlightenment : e17. Celles-ci sont d'ores et déjà utilisées par des distributions, ou sociétés : Yellow Dog, Openmoko, Elive, ThinkGos, Englobe, Ebuntu...

Aller plus loin

  • # Documentation

    Posté par  . Évalué à 9.

    Un petit lien vers la documentation [1] histoire qu'on puisse voir à quoi ça peut servir en vrai avec des exemples.

    [1] http://docs.enlightenment.org/api/eet/html/

  • # A tester !

    Posté par  . Évalué à 3.

    Personnellement, j'utilise le plus souvent KDE mais qd j'ai essayé Enlightement il y a qq mois, j'ai vraiment été bluffé par cet environnement. On commençait alors à parler des effets de bureau (3D, transparence ...) mais là j'étais vraiment surpris de voir à quel point c'était en avance sur son temps.

    Dommage cependant que les applis tierce (amarok ...) ne soit pas toujours bien utilisables.

    Au niveau de l'utilisation des ressources systèmes, je n'ai pas eu d'impressions de lourdeur mais les infos sur le net sont contradictoires : certains affirment qu'il est léger et d'autre qu'il est lourd ... Mais est-ce que l'on compare ce qui est comparable (mêmes applis, même "gadgets" ...)

    J'encourage donc à tester, rien que pour la curiosité.

    Ce n'est pas parce que les choses sont difficiles que nous n'osons pas. C'est parce que nous n'osons pas qu'elles sont difficiles. - Sénéque

    • [^] # Re: A tester !

      Posté par  . Évalué à 10.

      Au niveau de l'utilisation des ressources systèmes, je n'ai pas eu d'impressions de lourdeur mais les infos sur le net sont contradictoires : certains affirment qu'il est léger et d'autre qu'il est lourd ... Mais est-ce que l'on compare ce qui est comparable (mêmes applis, même "gadgets" ...)

      E16 était assez gourmand en ressource quand il est sorti, il fallait vraiment une machine puissante pour pouvoir l'utiliser (puissante pour l'époque, c'est à dire vers 1997 je crois)

      Mais E17, ça tourne impeccablement sur une config vraiment très légère genre vieux PIII

      • [^] # Re: A tester !

        Posté par  . Évalué à 1.

        Normal, E16 n'exploitait pas les capacités OpenGL des cartes graphiques à l'époque.

        • [^] # Re: A tester !

          Posté par  . Évalué à 1.

          E17 non plus, Rasterman n'est pas fan de l'API dés lors, tout est accèléré en soft.

      • [^] # Re: A tester !

        Posté par  . Évalué à 2.

        Moi j'utilisais Elive 1.0 en livecd sur un PII 266 avec 128mo de ram et une carte graphique neomagic (je saurais pas en dire plus), ca tournait impec et c'etait assez fluide

  • # Euh... Première page???

    Posté par  (site web personnel) . Évalué à 7.

    Corrigez-moi si je me trompe, mais la on ne parle pas de E17, mais d'une très petite API pour accéder à un fichier de données, de façon très simple.
    Genre sqlite, mais en 100x moins puissant (il n'y a aucune gestion de base de données)
    Je me demande pour quelle raison un version alpha d'une petit bout d'API a le droit à une "une"?
    Le même traitement sera possible pour la version alpha d'une version de Gconf (qui fait bien plus que cette API...)? ou pour tout autre petit bout de projet sur lequel on aura mis le mot "API" pour 4 commandes qui se battent en duel?
    Parce que API de ce style, il en sort des dizaines tous les jours (moins documentées, certes...)

    • [^] # Re: Euh... Première page???

      Posté par  . Évalué à 10.

      Parce que API de ce style, il en sort des dizaines tous les jours (moins documentées, certes...)

      Des gens qui bossent aussi bien que Rasterman et sont équipe, y'en a pas beaucoup, donc non, des apis de ce style, il en sort certainement pas tous les jours.

      Avoir un lib de bonne qualité pour la gestion des configurations, pour par exemple remplacer le pratique mais lent, lourd et par forcément pertinent XML dans ~55kB tout en ayant une gestion du stockage de rasters compatibles multi-architecture, franchement ca mérite une annonce avant la version 1.0, rien que pour dire qu'elle existe et qu'il faut la tester.

      • [^] # Re: Euh... Première page???

        Posté par  . Évalué à 4.

        Honnêtement si tu fais pas de relationnel, je vois mal l'intérêt de stocker ta conf dans un fichier binaire... Faire chier le monde ?
        (et je suis pas fan du tout du XML non plus pour de la conf)

        Pour des chunks de binaires, c'est déjà plus intéressant.

        Concernant la qualité de la biblio, si quelqu'un a envie d'y contribuer je lui suggère amicalement de commencer par réduire la complexité de la fonction _eet_data_descriptor_decode(), qui est vraiment totalement inabordable.
        Heureusement elle fait un peu exception et la plupart du code semble assez bon.

        • [^] # Re: Euh... Première page???

          Posté par  . Évalué à 1.

          Effectivement eet_data.c a besoin d'une bonne refactorisation/nettoyage de code. C'est prevu, mais pour la prochaine version (car ca risque de casser beaucoup de chose comme changement). C'est d'ailleur un prerequis a l'ajout du support de nouveau type de donnees comme les tableaux et les unions.

    • [^] # Re: Euh... Première page???

      Posté par  (site web personnel) . Évalué à 2.

      En fait je ne pense pas que la cible est la même, quand on voit les possibilités de sqlite on est quand même loin d'un simple gestion d'enregistrement, sauvegarde assisté pour une taille 7 fois plus grande.

      A voir sur cette page [http://www.sqlite.org/features.html], la connaissance de SQL (qui n'est pas commune dans le monde de l'embarqué) est forcément un pré-requis.

    • [^] # Re: Euh... Première page???

      Posté par  (site web personnel) . Évalué à 10.

      En fait e17 est sensé sortir après le port de Duke Nukem Forever sous Hurd, alors lorsqu'une bibliothèque du projet sort en version alpha, c'est vraiment la fête !

      ce commentaire est sous licence cc by 4 et précédentes

    • [^] # Re: Euh... Première page???

      Posté par  (site web personnel) . Évalué à 8.

      Genre sqlite, mais en 100x moins puissant

      Oui justement j'y pensais.

      Au final SQLite est un excellent choix comme format de fichier pour n'importe quel ensemble de données non-trivial.

      Portable, compact, rapide, structuré, gère jusqu'à 2 To de données, supporte les données numériques, textuelles et binaires... une base SQLite a tous les avantages, surtout par rapport à des formats de fichier maison (pas de parseurs à écrire, etc.)
      (Et ne me lancez pas sur l'XML !)

      En prime, la gestion des transactions vous permet d'éviter la corruption des fichiers lors de l'écriture (ACID).

      La librairie est solide, accessible de pratiquement tous les langages et la license n'est vraiment pas chiante.

      Que des avantages. J'aime de plus en plus SQLite.

      • [^] # Re: Euh... Première page???

        Posté par  . Évalué à 1.

        De mon expérience, ça n'empêche pas que si la base de données est corrompue ça nous pourrit la vie. Amarok (qui utilise SQLite) m'a fait ça il n'y a pas longtemps, en plantant jusqu'a ce que je supprime purement et simplement la base de données.

        • [^] # Re: Euh... Première page???

          Posté par  . Évalué à 2.

          Et avec un XML ça n'arrive pas ?

        • [^] # Re: Euh... Première page???

          Posté par  (site web personnel) . Évalué à 2.

          Peut-être une transaction mal fagotée ?

          Je n'ai jamais réussi à prendre SQLite en défaut (et c'est pas faute d'avoir essayé: base de 2 Go, extinction ou reset de l'ordinateur en plein milieu d'écritures, etc.)

          Firefox 2 utilise SQLite pour son système anti-phishing.
          Firefox 3, d'après ce que j'ai compris, utilisera massivement SQLite aussi pour les bookmarks, etc.

      • [^] # Re: Euh... Première page???

        Posté par  . Évalué à 4.

        le probleme c'est que les fichiers de conf ne sont plus alors lisibles simplement que par l'outil qui a servi a les creer, on ne peux plus rattraper une grosse boulette avec vim pas exemple

    • [^] # Re: Euh... Première page???

      Posté par  . Évalué à 6.

      A quand une news à la une pour débattre de quel type de news mérite d'etre à la une ?

    • [^] # Re: Euh... Première page???

      Posté par  . Évalué à 1.

      L'objectif de EET n'est pas uniquement de fournir du stockage.

      Mais aussi de permettre de serialiser une structure de donnees pour l'envoyer a un autre programme sur le reseau ou via une IPC (et effectivement de l'enregistrer sur le disque).

      Pour la partie stockage, les fichiers en eux meme peuvent contenir aujourd'hui des donnees comme des images (avec ou sans canal alpha, compresse ou non), des data serialises ou des data binaires.

      Enfin eet est designe pour etre principalement utlise en lecture avec tres tres peu d'ecriture. C'est bien pour des fichiers de configuration, les data des programmes et ca n'a pas le meme usage que sqlite, ni les meme perfs. C'est d'ailleur utiliser par e17 pour ses themes et sa configuration. C'est une bibliotheque principale pour le projet Enlightenment qui meriterait d'etre utiliser pour plus de chose.

      Enfin si vraiment on veut comparer eet et sqlite, sur mon athlon 64, j'ai libeet.so == 72ko et libsqlite3.so == 443ko.

      • [^] # Re: Euh... Première page???

        Posté par  . Évalué à 2.

        Enfin si vraiment on veut comparer eet et sqlite, sur mon athlon 64, j'ai libeet.so == 72ko et libsqlite3.so == 443ko.

        Je me demande si c'est vraiment valable comme comparaison , à l'époque où les disques durs faisaient 10mo Ok , mais maintenant le disque dur "etalon" quand tu l'achètes c'est 500Go ...
        ça n'a de sens que pour l'embarqué , et encore...

        • [^] # Re: Euh... Première page???

          Posté par  . Évalué à 4.

          Enlightement vise les environnements enbarqués et avec peu de mémoire. Pourquoi a ton avis c'est E17 qui est utilisé avec YellowDog PS3 : la PS3 n'a que 256Mo de mémoire.
          Alors ouais, rien à faire coté disque, mais coté mémoire gagner 350Ko, c'est énorme pour l'embarqué.
          Et en terme de performance, je ne voudrais pas avoir à comparer SQLite avec EET. Parceque sans conteste possible EET est _très_ loin devant. Rasterman est un maniaque de la performance. Ceux qui se sont "amusé" à lire des bouts de code d'imlib2, comprendrons de quoi je parle. EET a été pensé "from scratch" avec de toutes petites machines dans la tête. Rappelons que l'objectif des EFL est d'être portable sur toute plateforme et en particulier les cellulaires et les palmtop. Il faut pas oublier qui est l'employeur de Rasterman actuellement.

          Moi, ce que j'attends c'est EVAS en 1.0 final. Parce que ce jour-là on pourra mettre à la poubelle CAIRO (la comparaison en performance des 2 est à pleurer...) Peut-être une idée pour GTK3 ?

          anyway, mes 2cents d'un utilisateur de kde4 :D

        • [^] # Re: Euh... Première page???

          Posté par  . Évalué à 4.

          Juste comme ca, lorsque tu n'as que 20Mo de RAM, tu es bien content de pouvoir decider de n'utiliser que eet et de gagner au minimum 350ko (en realite un peu plus, car ca te fais des pages memoires de moins a manipuler pour l'OS).

          Et oui, il y a encore aujourd'hui des systemes qui n'ont quasiment pas de RAM, de CPU et une flash de petite taille. Alors autant rester efficace et utiliser des outils qui correspondent au besoin.

      • [^] # Re: Euh... Première page???

        Posté par  (site web personnel) . Évalué à 1.

        Enfin eet est designe pour etre principalement utlise en lecture avec tres tres peu d'ecriture.

        Ah ok je comprend.

        (Ma remaque n'était aucunement faite dans l'intention de rabaisser eet.)

  • # systèmes embarqués ??

    Posté par  (Mastodon) . Évalué à -2.

    "les systèmes embarqués comme sur les fermes de serveur multi core/CPU"

    on ne doit pas avoir la même définition de Systeme_Embarque

  • # codage/décodage

    Posté par  . Évalué à 1.

    Simple remarque de français, on dit normalement codage/décodage et coder/décoder, tout comme codec = codeur/décodeur (et non "encodec").
    Le "en" que certains mettent devant est un anglicisme (merci de ne pas me sortir tel dico en ligne, ils se trompent aussi ; ce n'est pas parce que c'est sur un site que c'est vrai).

    (c'était mes 2 centimes de combat perdu d'avance...)

    • [^] # Re: codage/décodage

      Posté par  (site web personnel) . Évalué à 7.

      > merci de ne pas me sortir tel dico en ligne, ils se trompent aussi ; ce n'est pas parce que c'est sur un site que c'est vrai

      De rien... Mais le fait que "encoder" soit dans le Robert et dans le dictionnaire de l'académie française, ça te convainc que tout le monde se trompe sauf toi ? D'après les dictionnaires qui sont censés faire référence, on peut donc encoder un message, c'est à dire le rédiger suivant un code.

      > c'était mes 2 centimes de combat perdu d'avance.

      • [^] # Re: codage/décodage

        Posté par  . Évalué à 1.

        Mais le fait que "encoder" soit dans le Robert

        Le Robert me paraît extrêmement rapide à entériner les changements de langue, on l'a vu par exemple avec le terme de "légumier ", lors de manifestations de producteurs de légumes. Normalement, un légumier c'est un récipient, et l'usage du mot comme "producteur de légume" a été mis dans le Robert dès l'année suivante, alors que c'était du jargon de spécialiste.

        En bon français, j'insiste, rédiger suivant un code c'est coder. En tous cas c'est toujours ainsi que je l'ai entendu lors de mes études (jusqu'au 3e cycle). Si tu lis un livre qui date de plus de 10 ans, tu n'y verras que la formulation de (par exemple) "message codé", en aucun cas "message encodé".

        • [^] # Re: codage/décodage

          Posté par  (site web personnel) . Évalué à 2.

          Si tu lis un livre qui date de plus de 10 ans, tu n'y verras que la formulation de (par exemple) "message codé", en aucun cas "message encodé".

          L'intérêt d'une langue vivante, c'est de... Vivre.

          • [^] # Re: codage/décodage

            Posté par  . Évalué à 3.

            Vivre oui, mais si c'est juste pour angliciser un mot qui fonctionnait bien avant, quel intérêt ?
            Je n'ai rien contre l'anglais, je préfère parler chaque langue au mieux. Au passage, "encoder" et "encodage" c'est moche, en plus d'avoir un préfixe inutile. À notre époque où on raccourcit et abrège les mots, c'est paradoxal d'en rallonger un...

        • [^] # Re: codage/décodage

          Posté par  (site web personnel) . Évalué à 6.

          Remarque 1 : le Robert sur lequel je me suis basé a 5 ans.
          Remarque 2 : le Robert en question date l'apparition de ce terme à 1960.
          Remarque 3 : les domaines d'utilisations sont la linguistique et l'informatique (ce qui fait que la date de 1960 est particulièrement cohérente)
          Remarque 4 : le dictionnaire de l'académie française n'est pas "rapide à entériner les changements de langue".
          Remarque 5 : le mot encoder est présent dans le Larousse encyclopédique de 1968.

          Oui, on parle de message codé, mais on dit aussi que l'on encode un message.

          Rappel : Ce combat est perdu d'avance...

          • [^] # Re: codage/décodage

            Posté par  . Évalué à 2.

            Oui, on parle de message codé, mais on dit aussi que l'on encode un message.

            Pour quiconque a une certaine expérience de l'informatique (je m'approche des 40 ans), on ne voyait pas le mot "encoder" il y a quelques années dans les forums et les sites Web.
            C'est vraiment l'arrivée de la compression audio (MP3) et vidéo (DivX et autres) qui a vu le déferlement de cette forme. Ce n'est pas difficile de comprendre que c'est l'influence de l'anglais et du "encoding" (je reconnais que ce n'est pas toujours facile de résister à un usage, sachant que dans notre métier peu de gens maîtrisent bien le français).

            Je me demande d'ailleurs pourquoi l'usage d'encrypter ne s'est pas plus répandu... Je dis ça mais je l'entends régulièrement quand même, là aussi quand on lit des docs avec du "encryption" partout ça finit par influencer.

            • [^] # Re: codage/décodage

              Posté par  (site web personnel) . Évalué à 2.

              bin décrypter c'est cohérent, tu n'as pas la clé pour lire : c'est lorsque Champollion a utilisé la Pierre_de_Rosette qu'il a pu déchiffrer les hiéroglyphes égyptiens.
              Chiffrer est cohérent, tu utilises une clé.
              Encrypter c'est jeter la clé avant de l'utiliser ? (au moins t'es sûr que même si quelqu'un la retrouve il aura du mal à déchiffrer :p).

              • [^] # Re: codage/décodage

                Posté par  (site web personnel) . Évalué à 4.

                Encrypter c'est jeter la clé avant de l'utiliser ? (au moins t'es sûr que même si quelqu'un la retrouve il aura du mal à déchiffrer :p).

                C'est marrant, c'est la définition que je donne à crypter.

                Sinon, je trouve nul l'utilisation de "encoder", pour le passage d'un format à un autre, j'utiliser "convertir". Je ne suis pas un spécialiste mais je doute que les formats numériques pour compresser soient juste des tables de concordances.

                • [^] # Re: codage/décodage

                  Posté par  . Évalué à 2.

                  Sinon, je trouve nul l'utilisation de "encoder", pour le passage d'un format à un autre, j'utiliser "convertir".

                  Je me fends d'un commentaire pour te dire que je suis entièrement d'accord. Je n'ai jamais compris pourquoi, pour les mp3 et les vidéos, on s'est mis à parler de codage (encoding), au lieu de compression (ce que c'est initialement pour les sons et les images, donc les vidéos) ; et comme tu le dis, conversion est un mot à la fois général et qui correspond bien à l'opération effectuée.

                • [^] # Re: codage/décodage

                  Posté par  (site web personnel) . Évalué à 3.

                  mon interrogation n'étais visiblement pas claire, soyons complètement clair : je ne comprends pas _du tout_ l'utilisation de crypter ni de encrypter. Effectivement, chiffrer me convient (mais pas pour la compression de format vidéo/audio), compression et conversion me conviennent aussi ;-)

        • [^] # Re: codage/décodage

          Posté par  (site web personnel) . Évalué à 2.

          ce qui m'a fait penser... j'ai été voir dans mon larousse à "crypter" (qui n'est à mon sens pas un mot français, le mot correct étant "chiffrer").
          Consternation, le mot existe bien, donnant la définition de "chiffrer", avec comme synonyme proposé "encoder".

          Où va le monde ?
          Bon sur ce je finis mon sandouiche avant de me regarder un petit dévédé

    • [^] # Re: codage/décodage

      Posté par  . Évalué à 10.

      toujours ma vieille blague pourrave que je ressors à chaque fois : c'est vraiment du culage de mouche tout ça...

      Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it

  • # coquilles ...

    Posté par  (site web personnel) . Évalué à 3.

    > dans un ficher unique à accès aléatoire

    Il faut traduire random access par accès arbitraire (i.e. un accès à n'importe quelle donnée, n'importe quand), qui s'oppose à un accès séquentiel, par octets ou blocks d'octets.

    > Eet est portable sur beaucoup d'architectures et de systèmes d'expoitation d'exploitation

    Adhérer à l'April, ça vous tente ?

    • [^] # Re: coquilles ...

      Posté par  . Évalué à 5.

      accès arbitraire:
      Dans mes premiers cours d'informatique (presque trente ans déjà...), on utilisait accès direct pour random access (et accès séquentiel pour sequential access).
      Depuis, je trouve très souvent accès direct et jamais accès arbitraire. Ton "Il faut traduire..." me semble donc un peu péremptoire.

      Par contre, je suis d'accord avec toi, accès aléatoire est une très mauvaise traduction : normalement, on connait la position des données dans le fichier; on ne se fie pas au hasard pour la trouver .... ;)

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.