GNOME 2.30.2, dernières révérences de l'honorable

Posté par . Modéré par Xavier Teyssier.
Tags :
28
3
juil.
2010
Gnome
Il y a quelques jours sortait GNOME 2.30.2. Au menu : correction de certains bugs gênants coté utilisateur, gros ajouts de documentation et de diverses traductions. Rien de bien folichon me direz-vous… Vraiment ?

Et bien pourtant, c'est une version extrêmement importante et lourde de sens pour tous le Gnomistes, et plus encore pour les anti-Gnomistes : après huit ans de service, cette mise à jour est la dernière de GNOME 2 qui va laisser place à GNOME 3 dès septembre prochain. GNOME 2, GNOME éternel, Toi la constante globale de l'univers linuxien, nous faudra-t-il réellement te quitter un jour ? Pourtant, c'est bien ce que nous prépare la communauté : une révérence soignée, mais une révérence quand même.

GNOME 2.30.2 ne sera pas une révolution. Il s'agit uniquement de corriger les derniers bugs importants et des fuites de mémoire. Tout comme les sous-versions précédentes. On ne peut s'empêcher de penser à ce ménage qu'on fait avant de fermer la maison dans laquelle on a passé ses vacances.

Mais peut-être faut-il être plus optimiste et considérer que les vacances ne se terminent pas, mais commencent. Il est vrai que Metacity se fait vieux et qu'il est unanimement reconnu comme limité, le Gnome-Shell qui prendra sa place laisse entrevoir un bureau en colonnes composite.

GNOME 3 sera aussi plus attachant : il s'intéressera à ce que vous faites et vous pourrez consulter votre historique dans Zeitgeist. Ses post-its Tomboy pourront se synchroniser via Internet pour que vous puissiez récupérer vos notes partout. Oui, GNOME 3 s'intéressera à vous et sera soucieux que vous vous y retrouviez. Pour ce faire, Yelp, le lecteur de manuel sera bien plus rapide, vous laissera mettre des signets sur les pages que vous considérez comme importantes et l'interface sera légèrement différente selon le document consulté.

GNOME 3 sera plus ludique, en facilitant la conversion des différents types de médias, supportant de base un certain nombre de webcams, et facilitera la configuration audio de votre système.

Oui, les vacances ne font peut-être que commencer avec GNOME 3, et qu'on rende hommage à GNOME 2 ou qu'on soit soulagé qu'il laisse sa place, on a quand même hâte de voir à quoi ressemblera la prochaine version.
  • # Confusion dans les versions

    Posté par (page perso) . Évalué à  10 .

    En fait la 2.30.2 est sortie le 23 juin, il s'agit bien de la dernière version de la série 2.x prévue, même si les mainteneurs sont invités à créer des versions 2.30.3 de leurs modules s'ils le jugent nécessaire.

    Par ailleurs, hier 1er juillet, ce n'est pas la 2.30.4 mais la 2.31.4 qui est sortie, c'est donc la quatrième version de développement de GNOME 2.31 (série qui donnera la version stable 3.0), le principal changement dans cette version est l'apparition de plus en plus de modules utilisant GTK+ 2.90 (qui donnera la version 3), avec une bonne part des bibliothèques de la pile déjà portées, et déjà quelques applications.

    Pour la suite ? Ce sera une 2.31.5, prévue le 14 juillet, elle devrait voir encore plus d'applications portées vers les nouvelles bibliothèques, et puis bien sûr toujours des nouvelles versions des différents modules, dont GNOME Shell, bien sûr.

    Le calendrier pour le cycle est visible ici : http://live.gnome.org/TwoPointThirtyone
  • # Gnome ...

    Posté par . Évalué à  10 .

    ou le bureau présidentiel.
  • # pulseaudio

    Posté par . Évalué à  3 .

    J'espère que les réglages de pulseaudio gèreront mieux les serveur distant. Parce que pour l'instant, je suis toujours obligé d'utiliser pulseaudio-device-chooser (qui est obsolète pour gnome) quand je veux renvoyer le son de mon laptop vers mon installation hifi.
  • # API de synchro

    Posté par (page perso) . Évalué à  10 .

    Tomboy qui se synchro via Internet c'est bien mais je trouve dommage que GNOME ne propose pas une API qui propose à chaque application de faire de même. Là chaque développeur doit réinventer la roue...
    Ca permettrait de plus aux applications desktop d'exploiter enfin Internet et de pouvoir concurrencer les application web, en synchronisant les données mais pourquoi pas aussi en proposant de les partager entre différent utilisateur GNOME.
    J'ai l'impression que KDE a un train d'avance là dessus en travaillant sur socialdesktop.

    http://nodecast.github.com/ncs/ bitmessage : BM-2DCNWJomzSWRQ54WcuVGF7XvKEybhdmLJ9

    • [^] # Re: API de synchro

      Posté par (page perso) . Évalué à  6 .

      Conduit ?
      • [^] # Re: API de synchro

        Posté par (page perso) . Évalué à  2 .

        Conduit ce qu'il y a de plus simple pour l'utilisateur et c'est lui renvoyer ce que la plateforme ne veut pas faire...

        http://nodecast.github.com/ncs/ bitmessage : BM-2DCNWJomzSWRQ54WcuVGF7XvKEybhdmLJ9

        • [^] # Re: API de synchro

          Posté par (page perso) . Évalué à  2 .

          c'est pas ce qu'il y a de plus simple pour tous les users, je voulais dire.

          http://nodecast.github.com/ncs/ bitmessage : BM-2DCNWJomzSWRQ54WcuVGF7XvKEybhdmLJ9

    • [^] # Re: API de synchro

      Posté par (page perso) . Évalué à  3 .

      J'ai l'impression que KDE a un train d'avance là dessus

      KDE4 est en avance d'une grosse rupture de continuité. Souvenez-vous, les premières versions de KDE4 étaient à peine utilisables.
      Il est à souhaiter que Gnome ne subisse pas un tel choc car KDE a fini par digérer Qt4 et est maintenant très performant. Gnome ne peut pas se permettre de refaire le calamiteux coup de KDE4.0 car la compétition entre KDE et Gnome en souffrirait, or elle est utile et nécessaire.
      • [^] # Re: API de synchro

        Posté par . Évalué à  7 .

        Heu.. Si KDE l'ai fait, Gnome peut se le permettre. Surtout que KDE4 commence à se stabiliser et à devenir moins bordélique. Je suis passé sous Gnome à cause de KDE4, si Gnome 3 me fait le même coup j'irai trouver refuge chez un KDE4 enfin utilisable.

        THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.

        • [^] # Re: API de synchro

          Posté par (page perso) . Évalué à  2 .

          Ca dépend quand même de la machine, ou plutôt de la RAM installée. J'ai 2 Go de RAM (et une "bonne vieille" carte ATI Radeon 7500 avec 64 Mo de mémoire). Je peux utiliser KDE 4 avec des effets de bureaux (bureau en cube + transparence) mais je dois absolument renoncer à affecter un papier peint à chaque bureau et, mieux, à n'utiliser que le strict minimum vraiment utile de gadgets Plasma sous peine de rendre mon système asthmatique.

          Le danger serait alors que Gnome 3 nous refasse le même coup que KDE 4 autant par des débuts non stables que par un accroissement d'exigence en quantité de mémoire RAM.
          • [^] # Re: API de synchro

            Posté par . Évalué à  3 .

            Ah non, je parlais pas de ces aspects bassement matériels (j'ai la chance d'utiliser quotidiennement une config qui poutre, machine de boulot en fait). Plutôt de l'utilisabilité au quotidien: gestion de deux écrans, 'panneau de configuration', bugs d'affichage, bugs d'économiseur d'écran, intégration des composants non KDE (Icedove et Iceweasel notamment). et de ce point de vue, entre KDE 3.5 (qui était vraiment dans l'esprit Lego et avait atteint une quasi-perfection), et KDE 4.x, on repart pratiquement de zéro.

            Du coup, vu que j'ai pas le temps de passer ma journée à contourner des bugs, pour l'instant j'en suis à Gnome et ça marche bien :)

            THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.

      • [^] # Re: API de synchro

        Posté par . Évalué à  2 .

        Gnome ne peut pas se permettre non plus de refaire le coup de Gnome2 avec les devellos déçus par les choix au niveau de l'interface et qui se barrent pour créer de nombreux forks en GTK2 de Gnome1 !

        Je me rappelle y'a pas si longtemps on en trouvais encore un dans le top 10 des projets les plus populaires sur gnomefiles ! De vrais cafards, ça refuse d'évoluer et ça survit à tout !
  • # Zeitgeist refusé

    Posté par (page perso) . Évalué à  7 .

    Zeitgeist a été refusé pour son inclusion dans gnome 3.0 (sans que rien ne soit fermé pour la suite). Ça a donné lieu à un certain nombre de débats avec plus ou moins d’arguments¹.
    Personnellement je trouve bien triste que cette technologie ne soit pas présente dès le début, ça sent le syndrome kde4. Zeitgeist est assez surprenant et j’aime bien cette « nouvelle » façon de naviguer dans ses documents (activités). Des plugins pour de nombreux éléments de gnomes arrivent (jusqu’à Getting Things Gnome, ou Hamster). Voir des outils comme sezen ou gnome-journal tourner me fait dire que c’est un mode de navigation qui m’irait assez bien (bon, je garde autojump² quoi qu’il en soit et qui mériterait d’être porté dans un navigateur graphique… comme une awesomebar du navigateur de fichier)

    Ça mériterait un journal… mais j’ai des couches a changer !

    [1] la réaction d’un des dev : [http://seilo.geekyogre.com/2010/06/my-take-on-zeitgeist-and-(...)]
    [2] pas assez de pub autour de cet outil génial dont le dev est ici, sur linuxfr, et qui m’est un indispensable de la console : [http://wiki.github.com/joelthelion/autojump/] d’autant qu’il semble que le développement se poursuive.
    • [^] # Re: Zeitgeist refusé

      Posté par . Évalué à  6 .

      J'utilise Zeigeist au TAF complé avec Docky (voir capture http://seilo.geekyogre.com/2010/04/docky-love/) et c'est vraiment génial. Qu'il soit dans gnome 3.0 ou non finalement ne changera rien pour moi, je l'installerai manuellement.
      • [^] # Re: Zeitgeist refusé

        Posté par . Évalué à  0 .

        Page not found.

        Sinon, Zeitgeist, il y a des chances pour que ta distribution l'installe directement, aussi.
        • [^] # Re: Zeitgeist refusé

          Posté par . Évalué à  4 .

          • [^] # Re: Zeitgeist refusé

            Posté par . Évalué à  1 .

            Effectivement, j'aurais du corriger tout seul, honte sur moi pour au moins 10 générations.
            • [^] # Re: Zeitgeist refusé

              Posté par . Évalué à  2 .

              mais pourquoi faire subir a tes momes le poids de tes erreurs? Ah la la cette manie de toujours faire supporter les conneries aux generations suivantes...
              • [^] # Re: Zeitgeist refusé

                Posté par . Évalué à  2 .

                J'ai écris «Honte sur moi pour 10 générations», pas «honte sur ma lignée pour 10 générations».


                La grande roue karmique…
                • [^] # Re: Zeitgeist refusé

                  Posté par . Évalué à  1 .

                  tu es un chat? Et encore un chat n'a que 9 vies
                  • [^] # Re: Zeitgeist refusé

                    Posté par . Évalué à  2 .

                    Dans certaines religions, le nombre de réincarnation n'est pas fixe, et dépends du comportement de l'individu pendant ses vies.
                    Par exemple, chez les Sikhs.
                    Ainsi, en étant maudit sur 10 générations, j'ai de fortes chances d'être ré-incarné au moins 9 fois.
                    Ce qui est vraiment la plaie !
      • [^] # Re: Zeitgeist refusé

        Posté par . Évalué à  3 .

        Zeitgeist c'est quoi dans ta capture écran ? (désolé mais je survole rapido, pas le temps de chercher)

        la liste des informations ouvertes relatives à ton appli où bien le truc immonde à la mac qui est le bureau ?

        car si c'est ça le bureau gnome 3 perso je change de suite !

        je suis comme une poule mouillée devant un mac ... je préfère encore windowmaker c'est dire !
    • [^] # Re: Gnome 3 refusé

      Posté par (page perso) . Évalué à  3 .

      Gnome 3 est amputé d'autres choses aussi, il faudra de nombreux mois avant d'avoir le Gnome 3 attendu :
      http://www.linuxcertif.com/news/breve/00268/

      Commentaire sous licence LPRAB - http://sam.zoy.org/lprab/

      • [^] # Re: Gnome 3 refusé

        Posté par (page perso) . Évalué à  6 .

        Cet article date d'un an et gtk3 est bien la version qui sera utilisée avec gnome 3.

        <mode detection lien trollant ON>
        Déjà un article qui commence avec copier Plasma et Nepomuk, c'est un peu n'importe quoi :
        - gnome-shell est une appli, pour un desktop sans fioriture, justement anti-gadget, et plasma une librairie pour faire des gadgets !
        - gnome 3 ne veut pas de web sémantique dans un premier temps (zeitgest refusé), et Tracker (dépendance externe) utilise les ontologies Nepomuk au lieu de réinventer la roue
        <mode detection lien trollant OFF>

        Sinon je ne vois pas de quoi il va être amputé ? Les changements majeurs de Gnome 3 :
        - gnome-shell
        - nettoyage du code en consolidant l'API de certaines bibliothèques dans Gtk-3 directement

        Dans KDE 4, il y a eu beaucoup de changement au niveau des librairies (qui sont géniales d'ailleurs) : il a fallu du temps pour les applications majeures afin d'être portées.

        Gnome-shell est une application, pas un framework comme plasma et Kde 4. Il n'y a rien à porter du tout !

        Gnome 3 est aussi l'occasion d'un gros nettoyage de code : au niveau des API supprimées (recommandées mais on peut utiliser Gtk2), et celles ajoutées (GSettings par exemple, mais c'est optionnel). Bien sûr un effort est fait pour que toutes les applis utilisent enfin des APIs propres et récentes, mais si ce n'est pas fait tout marchera comme avant.

        Cette phase de nettoyage avec Gtk3 c'est justement pour enfin faire de vrais changement dans Gtk 3.2 :)

        Après gnome-shell, on aimera ou on aimera pas, et dans ce cas là l'ancien panel et desktop seront toujours là pour ceux qui ne veulent pas changer. Dans tous les cas les applications auront évoluées en attendant.

        Par rapport aux design initial : http://www.gnome.org/~mccann/shell/design/GNOME_Shell-200911(...) on est pas si loin que ça (manque qd même pas mal de trucs sur les ).
        • [^] # Re: Gnome 3 refusé

          Posté par (page perso) . Évalué à  2 .

          Et mince, j'aurais dû mieux lire :(

          Commentaire sous licence LPRAB - http://sam.zoy.org/lprab/

        • [^] # Re: Gnome 3 refusé

          Posté par (page perso) . Évalué à  0 .

          un gnome 2.4 quoi...

          www.solutions-norenda.com

        • [^] # Re: Gnome 3 refusé

          Posté par (page perso) . Évalué à  2 .

          >>> Après gnome-shell, on aimera ou on aimera pas, et dans ce cas là l'ancien panel et desktop seront toujours là pour ceux qui ne veulent pas changer.

          Ils seront toujours là ad vitam aeternam ou juste pendant un certain temps pour que les gens "s'habituent" à Gnome Shell et qu'on puisse les virer ?
          Moi j'ai peur que dans 2 ou 3 ans on nous annonce la suppression du panel/desktop.
          • [^] # Re: Gnome 3 refusé

            Posté par (page perso) . Évalué à  3 .

            >Moi j'ai peur que dans 2 ou 3 ans on nous annonce la suppression du
            >panel/desktop.

            C'est ce qui est prévu, en tout cas ce que m'on dit des devs sur #gnomefr ;)

            Après, c'est une question d'habitude, et peut être que le panel gnome-shell sera moins rigide avec le temps.
    • [^] # Re: Zeitgeist refusé

      Posté par (page perso) . Évalué à  2 .

      Dans ton premier lien, j'ai justement répondu comme pas mal de personnes qu'il n'y a rien de mal, et que Zeitgest sera certainement inclu à la prochaine version.et qu'ils préfèreraient que Zeitgest (qui est un framework) soit plutôt intégré directement aux logiciels qu'il va améliorer, comme Nautilus, le desktop, rhythmbox, etc. Là ça déchirerait un max.

      Pour l'inclusion, le développeur principal proposait une application qui est complètement indépendante, et qui n'est pas passée par une revue ergonomique, ne ne s'est pas rapprochée des équipes de traduction et documentation. Il a prit ça pour un refus surtout lié à l'hébergement sur launchpad (c'est vrai que c'est dommage, surtout pour les traductions).

      C'est qd même gênant pour un desktop qui depuis quelques années essait un max d'avoir un environnement homogène et bien intégré.
      • [^] # Re: Zeitgeist refusé

        Posté par (page perso) . Évalué à  4 .

        Vraiment, je ne critique pas l’intégration ou non de Zeitgeist. Je le signale, c’est tout. Et regrette que ce ne soit pas le cas. Maintenant je veux bien croire que la décision n’a pas été prise à la légère.
        En y pensant je me dit malgré tout qu’intégrer le moteur aurait été intéressant pour que, le jour ou l’intégration dans les logiciels soit effective, on ait un peu de recul au niveau des logs de zeitgeist (oui, j’admet, c’est un peu tordu, mais zeitgeist sans historique, ça ne sert à rien).
        Et puis zeitgeist manque encore d’un « porn-mode » qui permettrait de le désactivé quand on ne veut pas « polluer » son historique. C’est prévu mais je n’ai pas encore vu de système pour en effet mettre zeitgest en pause.
        • [^] # Re: Zeitgeist refusé

          Posté par . Évalué à  2 .

          Et puis zeitgeist manque encore d’un « porn-mode » qui permettrait de le désactivé quand on ne veut pas « polluer » son historique.

          Bah y'a ça :
          $ zeitgeist-daemon --quit

          Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

        • [^] # Re: Zeitgeist refusé

          Posté par (page perso) . Évalué à  1 .

          Et puis zeitgeist manque encore d’un « porn-mode » qui permettrait de le désactivé quand on ne veut pas « polluer » son historique. C’est prévu mais je n’ai pas encore vu de système pour en effet mettre zeitgest en pause.

          On peut aussi assumer ses tendances et ne pas en avoir honte. Et si on est vraiment schizophrène, on peut aussi créer un compte utilisateur additionnel (j'ai bien fait un compte sandbox pour utiliser skype). Mais de toute façon, il me semble que Firefox à déjà un mode "private browsing".

          Mais c'est vrai que ça peut être utile pour plein de choses de pouvoir désactiver Zeitgeist, pas juste le porn :)
  • # Virez-nous Metacity et le gestionnaire d'aide

    Posté par . Évalué à  8 .

    J'adore Gnome, mais le gestionnaire d'aide prend un temps fou à se lancer et la recherche une éternité pour donner les résultats ... si le tout ne plante pas. Quant à Metacity ... je n'aime pas dire du mal des gestionnaires de fenêtres alors je l'ai remplacé par Openbox.

    Vivement Gnome 3 !
  • # ...

    Posté par . Évalué à  5 .

    Thomboy ? C'est pas ce truc en mono horrible que je désinstalle en premier ?
    je ne savais aps que ce truc allait être intégré à gnome3. J'ai bien fait de passer à wmii, moi !

    Bon, trève de troll, c'est quand-même bien que gnome change enfin de version en septembre. Je testerait.
    • [^] # Re: ...

      Posté par . Évalué à  2 .

      No comment sur le troll de mono. Par contre Tomboy est une superbe application et je ne peux plus m'en passer. Je me suis fait un wiki personnel vachement complet et c'est un vrai bonheur de pouvoir naviguer dans toutes mes notes avec le système de lien et pour la recherche j'utilise gnome-do qui me permet d'accèder à n'importe quelle note en quelques secondes.
    • [^] # Re: ...

      Posté par . Évalué à  2 .

      Bah faut dire qu'il est déjà intégré à GNOME 2. Et surtout, je le trouve extrêmement pratique, c'est l'une des raisons qui me font préférer GNOME à KDE.

      Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

    • [^] # Re: ...

      Posté par . Évalué à  8 .

      Thomboy ? C'est pas ce truc en mono horrible que je désinstalle en premier ?


      Aller faisons un petit effort, et disons-nous que Mono c'est bien, qu'est-ce que ça nous a apporté, au libre, je veux dire?

      L'ecosystème mono est fourni de combien de logiciels si "cool" qu'ils n'auraient pas pu être developpés avec un autre langage/platforme?

      L'interopérabilité avec les applis .NET? des exemples?

      Qu'est-ce qui justifie l'existence de Mono mais et surtout l'intégration à Gnome? Alors que ce bureau dispose d'API Python, Perl, Ruby et d'autres j'imagine...

      Honnêtement, je ne veux même pas "troller" à ce sujet, je veux juste comprendre la plus value.
      • [^] # Re: ...

        Posté par . Évalué à  2 .

        "Qu'est-ce qui justifie l'existence de Mono"

        Le simple fait qu'il y ai des développeur .Net justifie Mono.
        • [^] # Re: ...

          Posté par . Évalué à  9 .

          Qu'est-ce qui justifie l'existence de développeurs .net ? :-)

          (Ok, pataper /o\, je sors tout seul →[]).
        • [^] # Re: ...

          Posté par . Évalué à  3 .

          vala certainement, mono, je n'en suis pas si sûr.

          Une implémentation du langage C# en Java , ça serait pas mal par contre. :)

          Sedullus dux et princeps Lemovicum occiditur

          • [^] # Re: ...

            Posté par (page perso) . Évalué à  3 .

            Si tu parles de porter C# sur la machine virtuelle java, je trouve que ce serais dommage.

            Ça ne protégerais pas plus juridiquement que l'implémentation mono, et en plus, la machine virtuelle mono est pas mal :

            http://shootout.alioth.debian.org/u32q/benchmark.php?test=al(...)

            Envoyé depuis mon lapin.

            • [^] # Re: ...

              Posté par . Évalué à  2 .

              ben , non, perso je m'en fous un peu de la machine virtuelle Mono et des 800$ pour son SDK pour l'iPhone.

              Tiens, ça me fait penser à ce que disait Microsoft à l'époque d' OS/2 :
              " Nous, vouloir couler OS/2 ? Certainement pas, pour chaque OS/2 vendu, IBM nous reverse cinq fois ce qu'on obtiendrait en vendant nos propres licences !" ( ref nécessaire ^^ )

              Par contre, si on pouvait profiter de la puissance de NetBeans et Eclipse pour Vala ou pour un langage sur runtime ressemblant à C#, là, oui, ça serait porteur.

              Sedullus dux et princeps Lemovicum occiditur

      • [^] # Re: ...

        Posté par . Évalué à  5 .

        Qu'est-ce qui justifie l'existence de Mono mais et surtout l'intégration à Gnome? Alors que ce bureau dispose d'API Python, Perl, Ruby et d'autres j'imagine...

        Je dirais plutôt, pourquoi pas Mono, puisqu'on conserve bien Python, Perl ou Ruby ? En quoi ceux-ci sont plus légitimes que Mono ? Après tout, il y a déjà GTK.

        Bref, laisser les développeurs employer les langages et frameworks qu'ils connaissent et apprécient, et si vous n'êtes pas contents, ne les utilisez pas, point.

        Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

        • [^] # Re: ...

          Posté par . Évalué à  7 .

          pourquoi pas Mono, puisqu'on conserve bien Python, Perl ou Ruby ?
          Parce que le .NET sapusépalibre et de plus sécontroléparmicromousapulesbrevetslogiciels .
          • [^] # Re: ...

            Posté par . Évalué à  3 .

            Je cite https://secure.wikimedia.org/wikipedia/fr/wiki/Mono_(logicie(...) :

            Les technologies à la base de Mono, soumises à l'ECMA, ne sont pas problématiques. Ceci inclut aussi la couche de compatibilité Mono/Linux/GNOME, qui n'utilise pas des technologies pouvant être couvertes par des brevets de Microsoft. Donc, C#, les bibliothèques et autres couches logicielles du projet GNU ne sont pas concernés par ces préoccupations.


            Les seuls composants pouvant poser problèmes sont ceux de la couche de compatibilité Microsoft, ce qui fait que tous les projets uniquement pour Linux sont parfaitement sûrs.

            Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

            • [^] # Re: ...

              Posté par (page perso) . Évalué à  4 .

              cette sûreté relative ne s'étend pas à en:moonlight_(runtime) non plus,
              cf. http://fedoraproject.org/wiki/ForbiddenItems#Moonlight
            • [^] # Re: ...

              Posté par . Évalué à  5 .

              Les seuls composants pouvant poser problèmes sont ceux de la couche de compatibilité Microsoft, ce qui fait que tous les projets uniquement pour Linux sont parfaitement sûrs.

              Donc Mono n'a pas été créé dans un soucis d'interopérabilité afin de ne pas se voir larguer par Microsoft qui auraît imposé sa platforme à l'univers. J'ai pourtant cru voir que l'interopérabilité était l'argument premier à l'époque!

              Donc dans les faits:

              On voit que c'est inutile car une appli Mono (porte bien son nom tiens finalement :p ) est seulement réservé à Linux/Unix sous peine de... peines.

              Ensuite, ils ont tout simplement présumé des forces de Microsoft à dépasser Java.

              Je veux bien sortir le discours "politiquement bisounours", on est libre, la force du LL c'est la diversité, patati, patata... Mais là franchement, c'est de l'argent, du temps gaspillé et des CONTRAINTES en plus pour une chose dont la priorité pour l'écosystème du libre n'était vraiment, mais vraiment pas nécessaire!

              Cela étant, je ne dis pas détenir le savoir, donc si des arguments peuvent m'éclairer et étendre un plus l'ouverture de mon esprit, svp, faites.
              • [^] # Re: ...

                Posté par . Évalué à  5 .

                C'est pas du temps gaspillé, au contraire, puisque des logiciels ont été écrits avec Mono et ils fonctionnent.

                Le vrai gaspillage de temps, c'est de les réécrire en C ou autre, comme GNote qui a un train de retard sur Tomboy.

                Le fait est que des gens aiment développer en Mono, et d'autres apprécient les logiciels qui en découlent, c'est tout ce qui compte. J'utilise Tomboy et F-Spot, non parce qu'ils sont en C#, mais parce que je les trouve bien conçus.

                Pourquoi faut-il toujours se justifier ? Encore une fois, vous n'aimez pas, ne les utilisez pas et puis c'est tout.

                Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

                • [^] # Re: ...

                  Posté par (page perso) . Évalué à  7 .

                  >Le vrai gaspillage de temps

                  C'est le gaspillage de temps CPU...
      • [^] # Re: ...

        Posté par (page perso) . Évalué à  -4 .

        Bein c'est un problème, j'ai un portable pas tout jeune et dans Gnome, je n'ai aucune appli Python ni Mono.

        Honnêtement ça fait 10 ans que je bosse avec Java, et je comprends forcément ceux qui font du Python, du Mono ou même aimerait faire du Java : retourner au C ou C++ c'est juste une perte de temps et de qualité extraordinaire, vraiment.

        Il n'y a que ceux qui n'ont pas fait les deux au moins 2 ans qui ne peuvent pas comprendre.

        C'est sûr il y a 10 ans, je contribuais à Gnome, et j'aimais faire du C ou du C++. Mais sérieusement on est en 2010 !

        Python c'est aussi assez lent à lancer, même une appli bien faite (enfin c'est d'un autre ordre que Mono et Java tout de même). Je trouve Python super adapté aux applis de configuration (pas trop grosses, qui peuvent changer souvent). Par contre refactorer et maintenir du code à long terme c'est compliqué (pas d'outils sympa pour refactorer).

        Peut-être que la vraie alternative c'est Vala, même si bien sûr on perd les avantages de Mono et Java : debug fastoche, profiling fastoche, refactoring en 2s, compilation supra rapide, IDEs de grande qualité, etc. Et puis déjà qd Mono comme tu dis il n'y a pratiquement rien, alors en Java c'est le désert total.

        On gagne quand même sur le principal : l'écriture, la simplicité du code, et la gestion des références.

        C'est sûr sous Windows, les librairies .Net sont partie intégrante du système, alors c'est déjà bien plus rapide, et ça on ne l'aura jamais sous Gnome :p

        bordel, pourquoi il n'y a pas une solution qui déchire dans tous les coins, on pourrait écrire des trucs de malades en 2s :'(
        • [^] # Re: ...

          Posté par (page perso) . Évalué à  10 .

          Wé on va réécrire le Kernel en Python-Java-Mono \o/
        • [^] # Re: ...

          Posté par (page perso) . Évalué à  9 .

          C'est sûr il y a 10 ans, je contribuais à Gnome, et j'aimais faire du C ou du C++. Mais sérieusement on est en 2010 !

          Et alors? On ne peut pas écrire de code en C les années qui contiennent le chiffre 1?

          « Moi, lorsque je n’ai rien à dire, je veux qu’on le sache. » Raymond Devos

          • [^] # Re: ...

            Posté par . Évalué à  7 .

            C'est sûr il y a 10 ans, je contribuais à Gnome, et j'aimais faire du C ou du C++. Mais sérieusement on est en 2010 !

            Et alors? On ne peut pas écrire de code en C les années qui contiennent le chiffre 1?


            Il veut simplement dire que Gnome n'a pas evolué en 10 ans.

            --->[]
        • [^] # Re: ...

          Posté par . Évalué à  3 .

          Je ne comprends pas comment tu peux affirmer que Java est bien mieux que C++ puisque ces deux langages ont presque la même syntaxe, les mêmes paradigmes, etc.

          J'ai utilisé les deux. Ce que j'en sais: Java est l'équivalent d'un sous-ensemble de C++. On peut (à quelque chose près) traduire mot à mot du Java vers du C++, mais pas l'inverse.
          • [^] # Re: ...

            Posté par . Évalué à  3 .

            Je ne comprends pas comment tu peux affirmer que Java est bien mieux que C++ puisque ces deux langages ont presque la même syntaxe, les mêmes paradigmes, etc.

            Ah, oui, c'est bien connu: C++ fournit un ramasse-miettes.
            • [^] # Re: ...

              Posté par . Évalué à  4 .

              Le ramasse-miettes n'a jamais été un argument pour ou contre, tellement son usage est controversé.

              "Les programmeurs Lisp savent que la gestion de la mémoire est si importante qu'elle ne peut être laissée aux programmeurs. Les programmeurs C savent que la gestion de la mémoire est si importante qu'elle ne peut être laissée au système" (Bjarne Stroustrup)

              Compter sur le ramasse-miettes pour q'un programme fonctionne, c'est comme jetter ses déchets par la fenêtre de son automobile: pas besoin de savoir ce que ça génère, les autres sont là pour s'en occuper.
              • [^] # Re: ...

                Posté par (page perso) . Évalué à  4 .

                et compter sur un programmeur pour gérer la mémoire on voit ce que ça donne...

                tu prends à peu près n'importe qu'elle logiciel, tu regardes ses mises à jour et il y aura eu des correction au niveau de la mémoire...

                www.solutions-norenda.com

                • [^] # Re: ...

                  Posté par (page perso) . Évalué à  2 .

                  Sauf que les problèmes de mémoires classiques sont bien moins embêtants que les inconvénients d'un ramasse miettes.

                  Si un logiciel a une fuite de mémoire, chose plutôt courante (surtout sur gnome), il peut consommer plus de mémoire que ce dont il a besoin. Peut-être 15Mo de trop, au bout de quelques semaines (une fuite énorme est rapidement détectée).

                  Si un logiciel équivalent est écrit avec un ramasse miettes de merde, il va consommer dés le début 120Mo de trop, sans amélioration possible.

                  Les erreurs de corruption de la mémoire quant à elle sont plutôt rare, car si le logiciel est correctement testé, ça plante à la figure, et un débuggeur insulte assez correctement les developpeurs.

                  Envoyé depuis mon lapin.

                  • [^] # Re: ...

                    Posté par . Évalué à  -1 .

                    Si un logiciel équivalent est écrit avec un ramasse miettes de merde, il va consommer dés le début 120Mo de trop, sans amélioration possible.

                    Tout l'intérêt du ramasse-miettes intégré au langage, c'est qu'au lieu d'avoir un "ramasse-miettes de merde" spécifique à chaque logiciel un peu compliqué, tu as une plateforme commune qui est relativement mûrie et débuggée, et bien réglée (ou réglable, d'ailleurs).

                    C'est comme un compilateur : ça abstrait et mutualise un travail fastidieux (la traduction d'instructions haut niveau en code assembleur) au prix d'une petite perte potentielle d'efficacité par rapport à l'écriture d'une gestion bas niveau écrite à la main.

                    Après il y a toujours des inconditionnels de l'écriture d'ASM à la main mais, s'ils étaient encore nombreux dans les années 90, ils sont totalement marginaux aujourd'hui et font figure (fort compréhensiblement) de gentils zozos.

                    Les erreurs de corruption de la mémoire quant à elle sont plutôt rare, car si le logiciel est correctement testé, ça plante à la figure, et un débuggeur insulte assez correctement les developpeurs.

                    N'importe quoi. Correctement testé ne veut pas dire que tous les cas de figures sont prévisibles, et exhaustivement énumérables (sauf logiciel très simple). C'est d'autant plus le cas si le logiciel est multithreadé, d'ailleurs, à cause des problèmes très subtils que cela peut entraîner.

                    Dans le cas de Python, on trouve encore aujourd'hui des problèmes de gestion mémoire sur du code écrit parfois il y a 10 ou 15 ans. Je parle évidemment de l'interpréteur Python, plus précisément de la partie écrite en C... Après, libre à toi de penser qu'on fait de la merde et que tu es plus compétent.
                    • [^] # Re: ...

                      Posté par (page perso) . Évalué à  1 .

                      Le problème du ramasse miettes intégré au langage, c'est qu'il ne laisse pas le choix.

                      En C++, on peut gérer manuellement la mémoire si on a envi de faire le pro, on peut utiliser les pointeurs intelligents qui sont une alternative intéressante aux ramasses miettes (plus d'opérations, mais plus de constances et pas de consommation mémoire inutile), on peut utiliser un ramasse miettes, ou tout autre système.

                      Sinon, depuis des années, il y a eu des progrès énormes en termes de débuggeur, notamment avec Valgrind. Ça ne permet pas de détecter toutes les erreurs, mais c'est une énorme avancée à mon avis (en même temps, j'ai commencé à coder après la création de valgrind).

                      Au niveau du multi-threading, on est d'accord que tout les problèmes sont impossibles à détecter. Mais je ne vois pas ce que peut apporter un ramasse miettes là dedans, à part peut-être prolonger la durée de vie de certains objets, mais ça ne fait que cacher une erreur de conception.

                      Envoyé depuis mon lapin.

                      • [^] # Re: ...

                        Posté par . Évalué à  2 .

                        En C++, on peut gérer manuellement la mémoire si on a envi de faire le pro, on peut utiliser les pointeurs intelligents qui sont une alternative intéressante aux ramasses miettes (plus d'opérations, mais plus de constances et pas de consommation mémoire inutile), on peut utiliser un ramasse miettes, ou tout autre système.

                        Oui, on peut (« si on a envie de faire le pro », ce qui résume bien la motivation principale : je veux rejouer la bonne vieille légende du programmeur bas niveau qui maîtrise tout et écrit son gestionnaire mémoire à la main).
                        On peut aussi faire de l'assembleur pour s'affranchir de l'ABI imposée par le C, ou faire du passage de continuations, ou inventer sa propre représentation de nombres à virgule flottante.

                        La question, c'est de savoir pourquoi on aurait besoin de le faire (mis à part la motivation citée plus haut, toute psychologique). Et là, pour 99% des applications, il n'y a aucune réponse, parce qu'une gestion automatique conviendrait parfaitement et ferait de plus gagner énormément de temps d'écriture de code et de mise au point.
                    • [^] # Re: ...

                      Posté par . Évalué à  2 .

                      Foutaises !!!
            • [^] # Re: ...

              Posté par . Évalué à  5 .

              retourne lire la FAQ du C++ de y'a 15 ans, tu y trouveras tout un tas de librairies tierces proposées, dont plusieurs proposant des garbage collectors.

              par exemple, Great Circle par Geodesic Systems, qui avait énormément interessé Sun, au point de la coller dans sa JVM
              • [^] # Re: ...

                Posté par . Évalué à  -1 .

                Je ne vois pas le rapport. Je parle d'un ramasse-miettes en standard et intégré à la sémantique officielle du langage, pas d'une bibliothèque tierce partie avec sa propre API.
                Sinon, C aussi dispose d'un ramasse-miettes si on ajoute les bonnes bibliothèques.
                • [^] # Re: ...

                  Posté par . Évalué à  3 .

                  bah moi si. cette bibliothèque remplaçait tes new et compagnie et tu n'avais rien d'autre à faire, une API était bien là mais seulement si tu voulais absolument savoir combien tu avais de références sur un objet à un moment donné ou si tu avais bien relaché tous tes Pwet à la fin de ton programme

                  car tu pouvais utiliser cela et continuer à programmer proprement et méthodiquement tes desallocations et autres destructeurs, si tu voulais

                  et comme tu le dis toi-même, on n'a pas attendu 1995 et Java pour ne plus se casser la tête avec la mémoire. ni même 2010.
                  • [^] # Re: ...

                    Posté par . Évalué à  4 .

                    Dans ce cas, c'est à se demander pourquoi si peu de projets C++ utilisent une telle bibliothèque, même ceux qui ne sont pas vraiment bas niveau. Bon, évidemment, aujourd'hui les projets qui n'ont pas d'exigences bas niveau sont codés en C#, Java ou Python, mais il y a 10 ans ce n'était pas le cas... Et quand j'ai fait du C++ je n'ai jamais entendu personne envisager l'utilisation de telles bibliothèques, alors même qu'il n'y a rien de plus chiant que de passer son temps à écrire des destructeurs.

                    Un problème culturel peut-être ?
                    Ou peut-être, vraiment, le fait que ce n'est pas supporté en standard est-il un gros frein à l'adoption... Ce qui apporterait de l'eau à mon moulin.
                    • [^] # Re: ...

                      Posté par . Évalué à  2 .

                      > alors même qu'il n'y a rien de plus chiant que de passer son temps à écrire des destructeurs

                      ah, si, les accesseurs. CA, c'est ridicule.

                      sinon le reste c'et un peu comme les girafes ou les chinois, ce n'est pas parce que tu n'en vois pas dans ton pays qu'ils n'existent pas ou que ce sont des zozos marginaux

                      un problème culturel ? faut aller à la ville, des fois...
                    • [^] # Re: ...

                      Posté par (page perso) . Évalué à  2 .

                      http://www.boost.org/doc/libs/1_43_0/libs/smart_ptr/smart_pt(...)

                      La culture change antoine

                      En 10 ans la lib boost est apparue, elle devient un standard de fait, et ressemble au CPAN sous stéroïdes. Elle semble assez utilisée

                      J'ai aussi vu des devs C utilisant la lib C python afin d'utiliser les objets évolués et leurs garbage collectors (mais je trouve ça un peu porcasse).

                      Mais bon, à part en logiciel libre ou les gens développent parfois plus pour se faire plaisir que par efficacité, il faut admettre que le C et le C++ sont un peu tombés en désuétude. Dans mon enfance il y avait les chevaliers du zodiaque, et adulte dans le libre les chevaliers du C. Cette façon que l'on a de mouiller sur le C pur (hors noyau) me laisse perplexe.
                      En plus les binding haut niveau python/perl/ruby C existent ...


                      Si je devais recoder bas niveau, j'utiliserais ça :
                      http://ooc-lang.org/
                      * langage pivot compilant en C
                      * garbage collector
                      * gestion des modules
                      * objet
                      * élégant :)
            • [^] # Re: ...

              Posté par . Évalué à  2 .

              Pour te donner une idée j'ai vu une conférence d'un développeur de chez Sun (Ludovic Poitou) qui travail sur OpenDS. Il nous expliquait que dans un serveur ce qui est important c'est de pouvoir donner le temps maximal de réponse. Avec java et le full gc, ils en sont encore incapables. Généralement les requêtes sont traités de manière très rapide mais certaines vont mettre 10s pour être traitées parce que le full gc s'est lancé.

              Je suis dans ma tour d'ivoire (rien à foutre des autres, dites moi un truc pour moi), si je ne pose pas explicitement une question pour les 99%, les kévin, les Mm Michu alors c'est que je ne parle pas d'eux.

              • [^] # Re: ...

                Posté par . Évalué à  3 .

                Peut-être, et alors ?
                Le fait est que Java est un langage dont les allocations et désallocations sont gérées en standard par un ramasse-miette, ce qui rend la programmation Java fondalement différente de la programmation C++. Que ce soit lent ou pas n'est pas la question.

                (ensuite, je ne connais pas les implémentations Java, mais j'imagine que 10 seconde pour une collection complète, c'est sur des jeux de données sacrément costauds, ou des applis complètement mal écrites)
                • [^] # Re: ...

                  Posté par (page perso) . Évalué à  4 .

                  J'aurais tendance à dire les deux !

                  J'ai taté du processus java avec un foot print mémoire de 2.5 Go, du XmX poussé a 8 Go ( si c'est possib' ) qui partaient en 20 minutes et mettais dans les 30 à 40s sur un full GC ! Oui ca existe ! Oui y en avait besoin ! Oui c'était optimisé...( sigh )

                  Le problème très souvent du dev Java c'est qu'il recycle pas ses objets et se fiche notoirement de la mémoire, se reposant un peu trop sur le GC...... Et en activant les options +XX qui vont bien sur la jvm tu sors des graphiques de dérive mémoire et des stats de gc qui font mal, et tu dois mettre des baffes....

                  Et souvent je me disais / me dis que les dev java devraient soient
                  - faire un stage de C / C++
                  - soit avoir des machines avec 1Mo de RAM max

                  Fuse : j'en Use et Abuse !

                  • [^] # Re: ...

                    Posté par . Évalué à  3 .

                    c'est pas directement "trop se reposer sur le GC" le problème, c'est pisser du code sans trop vouloir comprendre ce qui se passe derrière

                    à un tout autre niveau pour les débutants Java c'est faire des manipulations de chaines avec String et + mais jamais StringBuffer
                    • [^] # Re: ...

                      Posté par . Évalué à  3 .

                      Déjà ça fait des années que les compilos remplacent tes concaténations par un bon vieux StringBuilder. Et comme tu peux le noter c'est StringBuilder qu'il faut utiliser (depuis la 1.4) et non StringBuffer qui est ThreadSafe et donc plus lent.

                      Donc les débutant ne cherchent peut-être pas à savoir comment ça marche derrière... Mais a priori ce ne sont pas les seuls...
                      • [^] # Re: ...

                        Posté par (page perso) . Évalué à  3 .

                        c'est StringBuilder qu'il faut utiliser (depuis la 1.4)

                        C'est depuis la 1.5 si on en croit http://java.sun.com/javase/6/docs/api/java/lang/StringBuilde(...) , comme beaucoup de développement se fait sur des jvm 1.4 et que StringBuilder est limité aux monothread, il est tout à fait possible et probable que Gniarf ne puisse utiliser que StringBuffer.

                        « Moi, lorsque je n’ai rien à dire, je veux qu’on le sache. » Raymond Devos

                        • [^] # Re: ...

                          Posté par . Évalué à  2 .

                          mea culpa, c'est 1.5, ma langue^W main a fourchée.

                          Pour ce qui est mono-thread, on va dire que les cas d'utilisation d'une String par plusieurs Thread restent marginaux....
                      • [^] # Re: ...

                        Posté par . Évalué à  2 .

                        Déjà ça fait des années que les compilos remplacent tes concaténations par un bon vieux StringBuilder.

                        Oui, mais seulement dans une même expression, et encore, s'il n'y a pas de parenthèses dans le chemin.
                        Un exemple typique de chose à ne pas faire c'est de la concaténation dans une boucle à coup de +=, par exemple

                        nb="";
                        for(int i=1;i<=10;i++){
                        nb+=" "+i;
                        }

                        Ça te crée autant de StringBuilder (si tu as la chance de pouvoir travailler avec java 1.5, sinon c'est StringBuffer) que de passage dans la boucle.
                        Et je l'ai déjà vu, parmis d'autres horreurs encore pire, et les gens se demandaient pourquoi leur bouzin était lent...
                        • [^] # Re: ...

                          Posté par . Évalué à  2 .

                          Dans un sens tu as raison. Mais ca me rappelle un post de Jeff Atwood: http://www.codinghorror.com/blog/2009/01/the-sad-tragedy-of-(...)

                          Oui c'est pas optimisé, oui c'est un goret qui a fait ca. Mais dans la vie réelle, si tu en arrives à ce que ce soit un problème de performance; alors tu as vraiment de la chance d'avoir une vie aussi simple. Par ce que tes problèmes ils se règlent en 1h de boulot. Sauf coder un hello world c'est pas ca qui fait la différence en général...
                          • [^] # Re: ...

                            Posté par . Évalué à  2 .

                            Certainement pas en 1h de boulot, plutôt quelques semaines, car, comme j'écrivais, le code était plein d'horreurs beaucoup plus graves que ces histoires de concaténations, il a fallu tout réécrire en s'appliquant à comprendre ce que le code aurait du faire.
                            Et c'est difficile de comprendre le code de quelqu'un qui ne comprend pas ce qu'il fait...
                  • [^] # Re: ...

                    Posté par (page perso) . Évalué à  3 .

                    si ça aurait pas été codé avec les pieds, tu aurais pas eu le problème....

                    tu sais tu es pas le seul au monde avec de tel système....

                    www.solutions-norenda.com

                    • [^] # Re: ...

                      Posté par . Évalué à  7 .

                      "si ça aurait pas été codé avec les pieds, tu aurais pas eu le problème...."
                      Si ça n'avait pas été conjugué avec les pieds, je n'aurais pas les yeux qui saignent...
      • [^] # Re: ...

        Posté par . Évalué à  5 .

        Ben, je sais pas toi mais moi .NET et surtout Mono m'ont apporté Vala, i.e. des gens qui ont été capables de remarquer que le C, ça n'allait plus et que Python, Ruby, C++ tout ça c'était pas adapté à GNOME. Ça fait un langage pas tout à fait au point encore, mais qui permet déjà d'écrire des programmes performants dans un langage moderne relativement simple.

        Moi j'aime bien.
        • [^] # Re: ...

          Posté par . Évalué à  2 .

          Je ne connais pas Vala, j'ai jeté un petit coup d'oeil sur wikipedia, ça a l'air intéressant.
          Où ça en est?
          Mais je ne l'utiliserais pas en production (!sic).
          Quelles applis actuellement tirent parti dans sa phase de developpement?

          Bref, vous avez des références, des bons bouquins à conseiller? Une communauté active?

          merci

          ps: Parcontre, je ne vois pas le lien direct avec Mono, si ce reprendre le paradigme C#.
          • [^] # Re: ...

            Posté par (page perso) . Évalué à  2 .

            http://live.gnome.org/Vala

            http://nodecast.github.com/ncs/ bitmessage : BM-2DCNWJomzSWRQ54WcuVGF7XvKEybhdmLJ9

          • [^] # Re: ...

            Posté par . Évalué à  5 .

            regarde mieux Vala et demande-toi :

            * pourquoi Vala serait mieux que du C qui n'irait plus
            * pourquoi Python, Ruby, C++ tout ça ne seraient pas adaptés à GNOME

            comment Vala répond à ces affirmations ? à chacun de voir

            par exemple, pour ma pomme,
            * Vala ne répond pas aux vrais problèmes que C me pose
            * Vala cause à GNOME à travers des fichiers d'interfaces (binding), technique qui précède largement Vala et GNOME.

            ces fichiers peuvent être générés automagiquement. au pire, soyons fous, ces autres langages pourraient récupérer ces mêmes fichiers (qui feraient partie de la distribution standard de GNOME) pour leurs propres bindings.

            voila là l'un des TRES rares apports de Vala à la scène du développement sous Linux : pour que Vala soit viable, il faut un accès aux fonctionnalités de GNOME, c'est à dire des bindings corrects, présents dès l'écriture de GNOME et pas rajoutés à la va-vite des années après. pratiquement comme de la documentation pour développeurs extérieurs au projet GNOME

            et ça c'est juste une conséquence de son coté "le langage officiel du moment de GNOME pour coder pour GNOME", pas du tout de ses caractéristiques techniques, bonnes ou mauvaises, innovatrices ou obsolètes^Wclassiques et éprouvées


            (maintenant, si j'étais pute, je parlerais de CORBA et autres Bonobo ...)
            • [^] # Re: ...

              Posté par . Évalué à  2 .

              Tu peux aussi voir Vala comme un langage informatique permettant de coder " comme en C# " en utilisant la glibc .
              2 questions :
              Vala ne répond pas aux vrais problèmes que C me pose
              forcément: la question est :
              - Connaissant une liste de projets développés en Vala , quels problèmes le C te pose que ne règle pas Vala ?
              ( http://live.gnome.org/Vala#Projects_Developed_in_Vala )

              - Est-ce un langage intéressant si on veut développer une application système de type " gestionnaire de matériels " incluant des références de matériel dans une base NoSQL , accessible via l'utilisateur et capable d'aller chercher le mdp root pour les demandes de modification , et, capable d'aller chercher des nouveautés de matériel dans une base distante via web , sous 3 types de systèmes d'exploitation distincts ? ( BSD , Linux et .... Haiku ? ) :)

              ( il va de soi que tu as le droit de ne pas répondre pour Haiku ) .

              Sedullus dux et princeps Lemovicum occiditur

Suivre le flux des commentaires

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