Journal Petites nouvelles...

Posté par (page perso) .
Tags : aucun
25
29
août
2008
* Launchpad sera open-source en 2009 :
http://arstechnica.com/journals/linux.ars/2008/07/23/mark-sh(...)

Launchpad est le gestionnaire de projet/bugs développé par Canonical pour développer Ubuntu. Launchpad est également ouvert aux projets extérieurs qui peuvent héberger leur version control (bzr) et leur bugs. Le problème c'est que Launchpad est propriétaire et que cela fait grincer beaucoup de dents. Mark Shuttleworth a annoncé que ce serait bientôt chose réglée et que Launchpad serait opensource dans les 12 mois.

Techniquement, launchpad est en python et est basé sur Zope/Plone.


* Intel rachète OpenedHand
http://o-hand.com/

Opened-Hand est une société fondée par des hackers du libre afin de développer des applications pour Linux embarqué. O-Hand a notamment contribué à Maemo avec le gestionnaire de fenêtres Matchbox, a pondu la suite PIM Pimlico (dates, contacts, ..), porté Evolution-Data-Server sur de l'embarqué, produit Poky, une distrib Linux embarquée, ...
Bref, ils sont très actifs dans le monde de Gnome Mobile.

Ils viennent d'être rachtetés par Intel avec le but avoué de contribuer à la plateforme Moblin, un projet visant à créer les softwares open-source pour la plateform MID d'Intel (et éventuellement pour d'autres ultra-portables).

Est-ce que O-Hand va continuer à supporter les architectures non-intel (comme Arm) ?


* Tomboy sous Windows
http://automorphic.blogspot.com/2008/08/hack-week-iii-tomboy(...)

Tomboy est un petit gestionnaire de notes/wiki personnel écrit en C#/Mono et intégré au bureau Gnome. Les utilisateurs acharnés de Tomboy vous le diront : Tomboy n'a pas d'équivalent sous Windows. À tel point que si vous utilisez Tomboy fréquemment, Windows vous semblera inutilisable.

Ce n'est plus le cas car Tomboy vient d'être porté sous Windows par Novell, qui affirme ainsi une fois de plus sa stratégie : que les gens sous Windows s'habituent à utiliser des applis issues du monde Linux afin que, dans un futur proche/moyen, plus rien ne les retiennent sous Windows.
  • # intel a fait de l'arm

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

    Le xscale, c'était fait par intel, et c'est de l'arm (http://en.wikipedia.org/wiki/XScale ). Enfin, visiblement, intel a revendu ça à marvell il y a quelques temps.
    • [^] # Re: intel a fait de l'arm

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

      J'en étais sûr... Intel fait du traffic d'ARM.
    • [^] # Re: intel a fait de l'arm

      Posté par . Évalué à 2.

      le StrongARM aussi, il me semble

      Mais effectivement tout ceci risque d' être remplacé par le (fantastique) ATOM.
      Moblin 2.0 va roxé :))
      • [^] # Re: intel a fait de l'arm

        Posté par . Évalué à 3.

        Remplacé?
        Par les successeurs d'Atom oui, mais pas par les Atom actuelles qui jouent dans une catégorie différentes (performance plus élevées que les ARM mais consommation plus élevée aussi) donc pour une utilisation différente..

        L'Atom est pas mal dans sa catégorie au niveau consommation electrique, mais coté chipset, c'est loin d'être ça..
        • [^] # Re: intel a fait de l'arm

          Posté par . Évalué à 1.

          A propos de l'Atom en utilisation "mobile", un article de Arstechnica sur le sujet est intéressant (RISC vs. CISC in the mobile era) :
          http://arstechnica.com/articles/paedia/risc-vs-cisc-mobile-e(...)

          Effectivement, l'Atom a de bonnes performances comparées à sa consommation, mais il n'est pas trivial pour Intel (ou autres fondeurs x86) de diminuer cette consommation tout en gardant un niveau de performances correctes, en partie à cause du jeu d'instruction x86. Les ARM ont toujours une longueur d'avance pour l'instant.

          --
          Unk
    • [^] # Re: intel a fait de l'arm

      Posté par . Évalué à 2.

      Les IXP aussi c'est de l'ARM, et à ce que je sache ils en font toujours ... non ?
  • # stratégie de Novell

    Posté par . Évalué à 10.

    je crois surtout que la stratégie de novell c'est de pousser le plus possible l'utilisation de Mono, basée sur une technologie de Microsoft, C#.

    Petit rappel :

    "Every line of code that is written to our standards is a small victory ; every line of code that is written to any other standard is a small defeat. Total victory, for DRG, is the universal adoption of our standards by developers, as this is an important step toward total victory for Microsoft itself: "A computer on every desk and in every home, running Microsoft software."

    Evangelism is War
    James Plamondon - technical evangelist


    Windows me semble inutilisable, mais pour plein d'autres raisons que Tomboy.

    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

    • [^] # Re: stratégie de Novell

      Posté par . Évalué à 9.

      Tout à fait. J'ai eu la même réaction.


      D'après le journal, on passe d'une situation où
      si vous utilisez Tomboy fréquemment, Windows vous semblera inutilisable.
      à une situation où
      Windows ne vous semblera pas (forcément) inutilisable si vous utilisez Tomboy fréquemment

      Quelle avancée, merci Novell en effet.


      De base quand je choisis un logiciel que je dois installer, quand je vois mono dans les dépendances je tique. Comment un dev qui choisit de faire un projet libre peut choisir un langage comme le C# ? Moi ça me donne l'impression que c'est fait par quelqu'un qui a des convictions mais pas trop.

      Si le mec est sous Windows, à la limite, je peux comprendre qu'il choisisse un langage en phase avec son environnement (et encore je ne comprends pas pourquoi il fait du libre. J'ai toujours trouvé bizarre ces "amateurs de libre" sous Windows. C'est comme un député dont les enfants téléchargent illégalement des musiques, mais qui vote quand même DADVSI, ça n'a aucun sens).
      Par contre s'il est sous un OS libre pourquoi est ce qu'il n'utiliserait pas les langages dispo ? Il a le choix : C, C++, perl, python, php, ruby, java, eiffel, pascal, tcl, haskell, lisaac, lua, ada, fortran, lisp, caml, YACC, ... même en bash ou zsh s'il veut.
      Pourquoi est ce qu'il irait choisir un langage fait par une companie dont l'éthique est discutable, qui fude à longueur de temps (brevets sur le noyau, get the facts, etc.), qui souhaite mettre des DRM partout (musique, vidéos, images, fonts, ebooks, ...) et porté par une entreprise guerre plus éthique qui se rapproche de MS au fur et à mesure du temps.

      Vraiment je dois être bête, mais je ne comprends pas. Je n'arrive pas à comprendre.


      Je pense que moins on utilisera mono dans le libre (et moins les utilisateurs/entreprises utiliserons les services de Novell, Suse y compris), mieux on se portera. Et plus ces deux sociétés (MS et Novell) se porterons mal, plus je serais satisfait. Des rayons de soleil éclairerons ma route et les oiseaux gazouillerons gaiement à mes côtés.

      C'est mon avis et je le partage. Désolé si je semble aigri, mais cette société qui m'était sympathique me déçoit de plus en plus.
      (Si vous êtes pas content défoulez vous => [inutile])
      • [^] # Re: stratégie de Novell

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

        > (Si vous êtes pas content défoulez vous => [inutile])

        Je vois pas en quoi ton commentaire est inutile ?! Tu donnes ton avis et c'est bien©. Vu qu'il n'y a pas encore de liens [d'accord avec ce post] et [pas d'accord avec ce post] si on n'est pas content, la meilleure chose à faire reste encore l'absention :).

        Quoi ? On me dit dans l'oreillette que c'est pas comme cela qu'est utilisé le système de vote sur DLFP ??? :)
      • [^] # Re: stratégie de Novell

        Posté par . Évalué à 6.

        J'adore F-Spot et Banshee, j'utilise donc mono. Personnellement, c'est des softs libres, pourquoi je ne les utiliserai pas ? après le jour où il y aura des problèmes avec des brevets, je repasserai vers d'autres softs comme Rhythmbox mais d'ici là, je continurai d'utiliser mono via Banshee, F-Spot et Tomboy.
      • [^] # Re: stratégie de Novell

        Posté par . Évalué à 7.

        >Il a le choix : C, C++, perl, python, php, ruby, java, eiffel, pascal, tcl, >haskell, lisaac, lua, ada, fortran, lisp, caml, YACC, ... même en bash >ou zsh s'il veut.

        Bah le C# comme tout langage a peut être des avantages dans certains cas. Je ne comprends pas le discours des gens qui plombe le C# pour des raisons que ce soit microsoft qui drive les specs. Je veux dire, si des gens lui trouve un avantages et deviens un langage utilisé, le libre devrais faire blocus?
        Au contraire, le fait que novell développe Mono, moi je trouve ca trés bien, ca prouve que la communauté open source sait trés bien s'adapter aux besoins des gens. Que dirais tu si C# venait a être à utiiser par plein de gens et que nous n'ayons pas d'implémentations libre. On aurais l'air bien malin tiens... La du coups ce seriat un serieux frein au pasage sous linux.
        • [^] # Re: stratégie de Novell

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

          Bah le C# comme tout langage a peut être des avantages dans certains cas. Je ne comprends pas le discours des gens qui plombe le C# pour des raisons que ce soit microsoft qui drive les specs. Je veux dire, si des gens lui trouve un avantages et deviens un langage utilisé, le libre devrais faire blocus?
          Ce sont les mêmes raisons qui ont fait que Java n'est devenu fréquentable que très récemment (http://www.gnu.org/philosophy/java-trap.fr.html )
          • [^] # Re: stratégie de Novell

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

            Les mêmes qui ont boycottés apache car la fondation fait beaucoup de java ?

            Et qui ont boycotté redhat qui a racheté jboss et qui a poussé gcj en payant des gens pour bosser dessus ?

            Et les mêmes qui ont boycottés nfs, nis, et openoffice car sun a gardé java proprio pendant longtemps ?
          • [^] # Re: stratégie de Novell

            Posté par . Évalué à 4.

            A la différence que Mono est libre alors que Java ne l'était pas !
            • [^] # Re: stratégie de Novell

              Posté par . Évalué à 6.

              mono est à .net ce que gcj était à sun-java. Une implementation libre. Mais si tu veux comparer, compare .net à sun-java et mono à gcj ou à openjdk.
              • [^] # Re: stratégie de Novell

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

                Non,

                Les implémentations libres de Java ne permettaient pas de lancer beaucoup d'applications Java (en tout cas aucune dans mon cas).

                Mono, l'implémentation libre de .NET permet de lancer pas mal d'applications. Et ça fait toute la différence.
      • [^] # Re: stratégie de Novell

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

        Très franchement, comme novell contribue au noyau, à open office, emploie des gens qui bosse sur gnome upstream ( vincent untz, hubert figuiere, pour citer les francais que je connais ), sponsorise des événements comme le guadec, ou le fosdem, a ouvert la partiticipation à la distribution Opensuse ( qui je le rappelle , était bien plus proprio avant que novell rachète la boite ), moi, ça me ferait chier que novell aille mal.

        Je trouve ça complètement hypocrite d'attaquer novell car tomboy est porté sur windows, alors que tout le monde applaudit la mozilla fondation d'avoir gagner des parts de marché grâce au portage de firefox sur les autres os.
      • [^] # Re: stratégie de Novell

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

        Moi, je dis mille fois merci à Novell pour Mono. Cela me donne une boite à outils supplémentaire pour facilement faire des applications qui tournent sous Linux et Windows.

        Dans mon cas bien concret, j'ai une application métier qui tourne sous Windows (pas un seul client n'utilise Linux et même si on propose une version Linux on n'a pas encore reçu la moindre demande réelle) et une version web de cette même application qui tourne sous Linux. Le cœur est le même, merci Mono.
        • [^] # Re: stratégie de Novell

          Posté par . Évalué à 2.

          Et pourquoi ne pas avoir utilisé Java si tu veux une application qui marche des deux côtés ?
          - T'as une VM des deux côtés
          - T'as des Composants graphiques sympas des deux côtés (Qt/SWT/Swing selon les goûts vs GTK/WinForms)
          - Un SDK qui fournit globalement les mêmes fonctionnalités


          Je cherche vraiment l'intérêt de mono ...
          • [^] # Re: stratégie de Novell

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

            En quoi java est-il un avantage par rapport à mono?

            Si on prend le problème par l'autre bout, je cherche vraiment l'intérêt de java ...
            • [^] # Re: stratégie de Novell

              Posté par . Évalué à 4.

              Ma question n'était pas un troll ...

              Java est sorti bien avant, et je ne vois pas l'intérêt d'utiliser Mono c'est tout, mais je pose quand même la question, en quoi mono est mieux que Java dans cette histoire?
              • [^] # Re: stratégie de Novell

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

                C'est pour des raisons historiques, car Microsoft n'a pas cassé la compatibilité avec toutes les DLLs. On a des routines de calcul scientifique codées en Fortran le tout dans une DLL, on peut facilement l'utiliser depuis C# et le bon vieux Fortran 77, cela se compile bien aussi sous Linux :)

                En gros, on peut doucement migrer une application MFC vers C# sans perdre les années de travail sur une partie du cœur.

                Je suppose que c'est possible de faire des accès à des DLLs avec Java (on le fait bien avec Python) mais bon, on fait la transition doucement, on a des contrôles activex dans la partie GUI...

                C'est donc un choix complètement orthogonal à la licence, Microsoft, etc. Quand je peux choisir, je prends plaisir avec d'autres langages que C#, mais il faut reconnaître, Microsoft a fait du joli travail avec ce langage et la VM qui va avec.
                • [^] # Re: stratégie de Novell

                  Posté par . Évalué à 2.

                  Merci pour la réponse

                  Il est vrai que pour le moment, java peut ouvrir des bibliothèques en C, mais ce n'est pas super à faire: soit les performances sont moyennes soit il faut suivre des convention de nommage ...
        • [^] # Re: stratégie de Novell

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

          Personnellement, ce que je reproche à .NET en général, c'est de n'avoir pas été conçu, ni même adapté pour être multi-plateforme. Ainsi, quand on regarde un exécutable Mono, quel est son type (déterminé avec le début du fichier) ? PE pour Windows. Ça oblige à des contorsions pour pouvoir les exécuter avec le binfmt_misc du noyau, par exemple.
      • [^] # Re: stratégie de Novell

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

        Par contre s'il est sous un OS libre pourquoi est ce qu'il n'utiliserait pas les langages dispo ? Il a le choix : C, C++, perl, python, php, ruby, java, eiffel, pascal, tcl, haskell, lisaac, lua, ada, fortran, lisp, caml, YACC, ... même en bash ou zsh s'il veut.

        Peut être parce qu'il préfère le langage C# ...

        Tout le monde ne se considère pas en guerre avec le monde propriétaire. C'est mon cas et je dois te dire que le fait que mono soit libre (au sens de la FSF et de l'OSI) me suffit. Et pour les brevets, je n'ai pas a m'en soucier, ils ne sont pas valide en Europe. Les accepter c'est se lier par avance inutilement.

        J'ai du mal à voir ce qu'on reproche à Mono spécifiquement (je ne parle pas de Novell ou Microsoft, juste Mono qui est un logiciel complètement libre)
  • # Pas le seul...

    Posté par . Évalué à 4.

    Je n'ai pas la prétention de connaitre Tomboy dans ses moindres détails (loin de là même..), mais à première vue, il semblerait qu'une application fort similaire existe bel et bien sous windows.

    Voir http://www.lsi-dev.com/index.php?mod=articles&ref=2
    • [^] # Re: Pas le seul...

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

      Pourquoi avoir une copie quand on peux avoir l'original ?

      http://www.microsoft.com/windows/partnerpack/desc/postit.htm

      * Requires the Microsoft .NET Framework 1.1
      • [^] # Re: Pas le seul...

        Posté par . Évalué à 3.

        pour ne pas avoir ce glaireux "Post-it! Notes" dans chacun de ces petits carrés jaunes à l'écran ?

        pour ne pas se taper ce "Microsoft .NET Framework 1.1" tout autant glaireux alors que codé correctement ce bazar prend 500 ko à tout casser ? on le trouvait à l'époque en bundle de... Netscape Communicator 4.5 ou 6 ou 7...
    • [^] # Re: Pas le seul...

      Posté par . Évalué à 2.

      A première vue également, Tomboy est bien plus complet, entre les liens "hypertexte" dans les notes (pour lier les notes entres elles), le système de recherche, et tout un petit tas de plugins plus ou moins intéressants, il fait bien plus qu'un simple système de post-it sur l'écran.

      Sinon il serait un logiciel comme un autre et on se poserai même pas la question du langage dans lequel il est écrit.
  • # Délai ?

    Posté par . Évalué à 9.

    Le projet Launchpad est bien entièrement conçu par Conical ? Quel est donc ce délai ce 12 mois ? Si il le souhaitais, il ne pourait pas le sortir dans 12 jours ?
    Un an pour librer un projet comme ça, où il n'y a pas de développeur à contacter à droite à gauche, j'ai du mal à comprendre…
    • [^] # Re: Délai ?

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

      Libérer un projet est bien plus compliqué qu'on ne le pense généralement. Il faut tout d'abord vérifier si on a bien tous les droits sur tout (et il suffit d'utiliser une petite librairie pour que ça ne soit plus le cas). Il faut faire un gros audit du code, retirer les commentaires privés, les références internes, etc..

      Ensuite, en théorie, là tu peux publier ton machin en opensource sous forme d'un bon gros tar gz.

      Mais en pratique, pour que ça aie du sens, il faut que tu établisses une structure pour permettre aux gens de contribuer tout en réutilisant toi-même leur travail et en évitant la fragmentation à outrance, tu dois mettre en place des règles, des outils, définir des procédures, établir l'infrastructure, écrire un minimum de doc.

      Franchement, prendre du code existant pour en faire un projet opensource, c'est un investissement réel et important.

      Après, on pourrait arguer que si ils avaient fait Launchpad direct opensource, ils n'auraient pas eu tout ces problèmes. Ce n'est pas impossible, je n'en sais rien.
      • [^] # Re: Délai ?

        Posté par . Évalué à 4.

        Arrête moi si je me trompe, mais Launchpad c'est pas déjà sa propre infrastructure de dev déjà en place ?

        En fait, tout ce temps, c'était juste la mise en place de "l'infrastructure et des outils", quoi :)
      • [^] # Re: Délai ?

        Posté par . Évalué à 5.

        Merci Ploum de toutes ces précisions.
        Par contre, concernant Launchpad, on aurait quand même pu espérer qui crée directement du code relativement facilement libérable. Je trouve ça étonnant que bossant pour le libre de ne pas prévoir cela dès le début et de devoir après coup dépenser et perdre une energie considérable pour corriger le tir.
        • [^] # Re: Délai ?

          Posté par . Évalué à 10.

          Moi aussi je trouve ça bizarre qu'ils n'aient pas prévu ça dès le début. On peut donc y voir deux types de comportements différents :
          - soient c'est des branques, ils n'ont pas prévu
          - soit c'est des cons, ils voulaient un truc proprio depuis le début
          Voilà, c'était la critique utile de la soirée.
          • [^] # Re: Délai ?

            Posté par . Évalué à 3.

            donc en gros même si Microsoft voulait de tout son coeur libérer le code de Windows XP dès maintenant, on ne pourrait voir le code qu'en 2042 (en étant optimiste) ?

            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

    • [^] # Re: Délai ?

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

      Peut-être doivent-il vérifier qu'il n'y a pas de code piquer ailleurs dans leur code. Faire une sorte d'audit.

      Peut-être même un petit nettoyage pour pas qu'on leur disent qu'ils code comme des pieds.
      • [^] # Re: Délai ?

        Posté par . Évalué à 3.

        c'est clair, s'il y a des morceaux tiers sous gplv2 et qu'ils comptent le sortir en AGPLv3, il faut passer par la case réécriture.
        • [^] # Re: Délai ?

          Posté par . Évalué à 0.

          Comme d'hab, ça moinsse sans arguments, la flemme classique des moinsseurs anonymes...

          pourtant il me semble bien que Canonical considérait sérieusement l'option AGPLv3

Suivre le flux des commentaires

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