Que penser du rachat de Novell ?

Posté par  . Modéré par Florent Zara.
Étiquettes :
34
25
nov.
2010
Suse
Il y a deux jours une annonce très importante pour Linux et le logiciel libre en général a été faite. La compagnie Novell a été rachetée pour deux milliards de dollars par un fonds d'investissement américain du nom de Attachmate. En marge de cette vente, il a été annoncé la cession d'une partie des brevets détenus par Novell en faveur d'une compagnie sous-marin de Microsoft Corp, CPTN Holdings LLC.

Très peu de détails sont connus pour le moment, mais de très nombreuses questions émergent petit à petit et il semble de plus en plus probable que cette annonce soit un des pires scénarios catastrophes que l'on puisse imaginer.

Voici une liste non exhaustive des questions que l'on peut se poser :
  • "Qui récupère la propriété de Unix ?". En effet, comme cela a été démontré lors du procès SCO, cette dernière appartient à Novell ;
  • Quels sont les brevets récupérés par le consortium dirigé par Microsoft ? Sont-ils utilisés dans le noyau Linux (les mauvaises langues diront que si oui Microsoft Corp aurait enfin ses centaines de violations de brevets...) ? ;
  • Quel est l'impact sur OIN ? Ne connaissant pas le fonctionnement de cette organisation est-ce que la participation consistait juste en une promesse très généraliste ou dans une liste de brevets bien définis ?
  • Que vont devenir les développeurs de Linux et de logiciels libres dans la nouvelle entreprise ? Rappelons que le numéro 2 du noyau, Greg Kroah Hartman, est employé par Novell. Un fonds d'investissement n'ayant pour unique raison d'être que de faire de l'argent, il est assez peu probable qu'une politique à long terme soit menée.

Naturellement les scénarios les plus pessimistes font aussi leur apparition comme on peut le lire sur [ITwire]. Une analyse plus poussée mais en anglais peut être lue sur le site Groklaw.

Il est probablement aussi important de signaler que pour le moment le rachat n'a été que soumis à la SEC et qu'il y a déjà deux groupes d'actionnaires qui entament une procédure contre cette vente (voir la fin de l'article sur le site Groklaw). Un journal succinct avait parlé de cela mais vu l'importance de Novell dans le monde de Linux et plus généralement du logiciel libre, le sujet méritait une dépêche.

Aller plus loin

  • # google est ton ami

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

    Ne connaissant pas le fonctionnement de cette organisation est-ce que la participation consistait juste en une promesse très généraliste ou dans une liste de brevets bien définis ?
    Y'a une liste bien définie :
    http://www.openinventionnetwork.com/pat_owned.php
  • # Les droits sur Unix ne font pas partie du lot racheté à Novell par M$

    Posté par  . Évalué à 4.

  • # Contribution au noyau Linux

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

    Pas d’inquiétude, Canonical est là pour reprendre le flambeau !!
    Ah... on me dit que non...
  • # Bonne nouvelle

    Posté par  . Évalué à 10.

    Au risque d'aller à contre courant, je trouve que c'est plutôt une bonne nouvelle.

    Novell, en fait de caméléon vert était plutôt un mouton noir dans le libre.

    Entre les accords fudesques avec MS pour faire croire que MS peut attaquer tout le monde sauf Novell, le chevalier blanc qui met en sécurité les utilisateurs de leur distribution et mono qui crée une autre insécurité juridique, Novell était plus l'ami qui vous dispense de la nécessité d'avoir des ennemis.

    Alors certes, c'est triste pour reg Kroah Hartman, qui est certainement la partie émergée de l'iceberg. Je pense qu'il ne sera pas difficile pour le numéro deux du noyau pour trouver un autre financement pour continuer ses activités. Les boites (google ? Red Hat ? Oracle ? ...) ne manquent pas. Ou peut être que la Linux Foudation pourrait l'embaucher, comme elle l'a fait pour Linus Torvalds suite à la baisse de forme de transmetta ? Encore ce serait un mainteneur d'un sous-sytème obscur ou un contributeur de base, je ne dis pas. Mais là, j'ai peu de craintes pour lui.

    Je me fais plus de soucis pour tout ce qu'on ne voit pas. Mais au bout du compte, même si ça risque de pénaliser certains projets on risque de se retrouver avec une situation plus claire et plus saine et ce n'est pas une mauvaise chose.

    Si Novell pouvait mourir, je n'en serais pas malheureux. Surtout si ça emporte mono et Suse dans la tombe au passage.
    • [^] # Re: Bonne nouvelle

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

      >>> Je pense qu'il ne sera pas difficile pour le numéro deux du noyau

      Le numéro deux du noyau c'est plutôt Andrew Morton que Greg Kroah Hartman.
      Sinon sur le fond tu as raison, je ne me fait aucun souci pour lui si il décide de changer d'employeur.
      • [^] # Re: Bonne nouvelle

        Posté par  . Évalué à 3.

        Le numéro deux du noyau c'est plutôt Andrew Morton que Greg Kroah Hartman. C'est ce que j'ai pensé en lisant la dépêche.

        « Tiens, ça a changé ? ».

        Ca me semblait bizarre, mais vu que la dépêche a été rédigé par quelqu'un qui s'y connais (je suppose) et relue par une demie-douzaine de relectmodos, je me suis dit que ça devait être une information fiable.

        Mais bon, indépendamment du numéro, non seulement il a un rôle important, mais en plus il est extrêmement médiatisé (relativement à un développeur Linux s'entend).
        • [^] # Re: Bonne nouvelle

          Posté par  . Évalué à 4.

          Ca me semblait bizarre, mais vu que la dépêche a été rédigé par quelqu'un qui s'y connais (je suppose) et relue par une demie-douzaine de relectmodos, je me suis dit que ça devait être une information fiable.

          Moi m'y connaitre? Non je suis un vulgaire trolleur :)

          Et oui j'ai tout a fait pu me tromper sur le sujet. De tout de facon GKH qu'il soit numero 2, 3 ou 4 c'est un detail, le plus important c'est que ce soit un contributeur majeur du kernel et il me semble celui qui fait les backports du kernel de dev vers ceux utilise par les distribs.
    • [^] # Re: Bonne nouvelle

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

      Surtout si ça emporte mono et Suse dans la tombe au passage.
      Hé ho, Yast a été libéré non ? Là on tombe vraiment dans l'ultralibéralisme Mr Kerviel...
      • [^] # Re: Bonne nouvelle

        Posté par  . Évalué à 6.

        Hé ho, Yast a été libéré non ? Je ne vois pas le rapport.

        J'ai toujours considéré que faire de la pub à Suse, c'était implicitement soutenir Novell. Moins il y a d'utilisateurs de Suse (communautaire ou pas), moins il y a de contributions, moins la distribution peut se différencier des autres, moins Novell a de l'influence, moins Novell peut être néfaste au logiciel libre.


        Là on tombe vraiment dans l'ultralibéralisme Mr Kerviel... J'ai bien peur de ne pas comprendre la relation de cause à effet entre ma phrase et le libéralisme. Est ce qu'il serait possible d'avoir plus de précisions, M. letoff ?
        • [^] # Re: Bonne nouvelle

          Posté par  . Évalué à 1.

          Là on tombe vraiment dans l'ultralibéralisme Mr Kerviel...
          J'ai bien peur de ne pas comprendre la relation de cause à effet entre ma phrase et le libéralisme. Est ce qu'il serait possible d'avoir plus de précisions, M. letoff ?


          Regarde plus attentivement ton pseudo j_kerviel, tu y verras peut-être une relation de cause a effet.
      • [^] # Re: Bonne nouvelle

        Posté par  . Évalué à 3.

        mais personne en dehors de opensuse et ses derives ne l'utilisent car libere trop tard.
      • [^] # Re: Bonne nouvelle

        Posté par  . Évalué à 3.


        Puis c'est aussi la mort de nombreux trolls.

        Enfin pour mono, j'ai des doutes sur sa chute, surtout maintenant que F# a été libéré.
    • [^] # Re: Bonne nouvelle

      Posté par  . Évalué à 9.

      "Si Novell pouvait mourir, je n'en serais pas malheureux. Surtout si ça emporte mono et Suse dans la tombe au passage. "

      Personnellement après des débuts difficiles sur Mandrake 9.1, c'est Suse 9.1 qui a fait de moi un Linuxien peu de temps après, c'était vraiment une excellente distribution.
      (ça a été un peu plus difficile par contre avec le passage au x86_64).

      Et pas extension je suis devenu plus tard libriste.
      Même si à l'époque Yast n'était pas libre (ça a changé depuis), le système fournissait principalement des logiciels libres.
      Donc je pense qu'il fait pas être sectaire, je sais pas trop ou ça en est maintenant (j'ai connu entre temps Debian et Archlinux), mais il y a toutes les chances pour qu'OpenSuse soit un très bon SE et qu'il pousse des gens à decouvrir Linux et le libre.

      Concernant Mono c'est un peu plus délicat.
      D'un côté c'est un langage et une plateforme venant de Microsoft donc forcément au début on est un peu réticent.
      Mais il se trouve que pour le boulot j'ai dû me mettre au C# (au passage c'est vraiment de la riguolade quand on a des bases de C++) et je dois dire que c'est assez bien penser.

      De plus le fait qu'il y ait quelqu'un pour se dévouer à développer Mono on y gagne beaucoup en intéropérabilité.
      Je rappelle que Mono est libre, faut pas dénigrer le truc uniquement par ce que c'est une implémentation de .NET qui vient de Microsoft.

      Dans ce cas on pourrait dire également que le mec qui s'occupe de maintenir gcc sur Windows est un traître, qu'il vole le boulot de GNU pour le mettre à disposition d'utilisateurs d'une plateforme propriétaire. Et que dire de MinGW ou Cygwin !!!

      Et il sont bien entendu indispensables, à commencer pour moi. (programmer sur Windows avec kate/kwrite avec gcc dans une console bash, tout ça grace à MinGW, moi je dis merci, sinon ça serait avec Visual Studio).

      Ben Mono c'est pareil, ça peut déranger pour les sectaires, mais heuresement qu'il existe, sinon il faudrait se contenter de l'implémentation de Microsoft, avec les outils qui vont avec !
      • [^] # Re: Bonne nouvelle

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

        Je rappelle que Mono est libre, faut pas dénigrer le truc uniquement par ce que c'est une implémentation de .NET qui vient de Microsoft.

        Même libre, il reste le problème de ces ****** de brevets. Tant qu'on aura pas brûlé le dernier consultant en propriété intellectuelle avec les derniers brevets, on n'aura pas la paix.

        Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

        • [^] # Re: Bonne nouvelle

          Posté par  . Évalué à 1.

          Quels brevets ?

          Seule la couche de compatibilité Microsoft peut poser des problèmes, mais pour développer des applications purement Linux, il n'y a aucun risque. Cette couche n'est d'ailleurs pas nécessairement installée.

          Pour tout le reste, Mono implémente soit des technologies standardisées par l'ECMA et dont l'implémentation est libre, soit des technologies propres qui ne violent aucun brevet (GTK#, Gstreamer, etc).

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

          • [^] # Re: Bonne nouvelle

            Posté par  . Évalué à 6.

            tu rigoles j'espere meme De Icaza n'ose pas aller aussi loin que toi. Il y a bien longtemps il etait question de separere mono en deux parties: une sans risque et "couverte" par la promesse Microsoft et une plus tendu diront nous. Seulement cela n'a jamais ete fait et ne sera jamais fait.
            Au passage la promesse ne concerne qu'une seule implementation de .Net, celle normalise a l'ECMA il y a bien longtemps, et uniquement si elle est complete.

            Donc dire que mono est sans risque c'est etre un "bisounours".

            Je vous laisse trouver les liens vous memes cela n'est pas difficile.
            • [^] # Re: Bonne nouvelle

              Posté par  . Évalué à 4.

              Debian propose de nombreux packages Mono, et dont en particulier :
              * libmono-microsoft-visualbasic8.0-cil - Visual Basic 2005 runtime libraries for Mono
              * libmono-microsoft-build2.0-cil - Mono Microsoft.Build libraries
              * libmono-microsoft7.0-cil - Mono Microsoft libraries (for CLI 1.0)
              * libmono-microsoft8.0-cil - Mono Microsoft libraries (for CLI 2.0)

              Donc si, c'est bien séparé.

              Et quand on voit l'histoire de FAT32, le noyau lui-même n'est pas à l'abri de ce genre de troll, et Mono ne pose pas plus de risque.

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

              • [^] # Re: Bonne nouvelle

                Posté par  . Évalué à 7.

                La on parle du travail d'une distribution et encore il n'est absolument pas certains que la separation soit complete (si c'est ce que represente ces paquets). De plus la promesse avait ete faite par l'equipe mono qui ne l'a jamais remplis.

                http://nocturn.vsbnet.be/content/get-facts-mono

                * Mono implements a lot more than the ECMA parts, De Icaza’s promise to seperate mono into safe and non-safe parts was never fulfilled

                http://www.the-source.com/2010/11/mono-criticism-uninformed-(...)
                • [^] # Re: Bonne nouvelle

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

                  Utiliser mono, c'est risquer d'enfreindre un brevet logiciel, il ne faut pas le nier, que tu le coupes en 2 ou 4 n'y changera pas grand chose.
                  Mais il est particulièrement malhonnête de ne pas mentionner également que :
                  - Jusqu'à preuve du contraire, on ne parle d'aucune infraction concrête mais uniquement de "possibles" litiges sans que l'on sache vraiment de quel code on parle ni de quel brevet.
                  - Utiliser Linux, c'est risquer d'enfreindre un brevet logiciel.
                  - Utiliser [cequevousvoulez], c'est risquer d'enfreindre un brevet logiciel.
                  - Debian semble penser qu'il est plus avantageux de proposer Mono à leurs utilisateur que de céder au troll des brevets.
                  - Fedora semble penser qu'il est plus avantageux de proposer Mono à leurs utilisateur que de céder au troll des brevets.
                  - Ubuntu semble penser qu'il est plus avantageux de proposer Mono à leurs utilisateur que de céder au troll des brevets.

                  Le plus drôle dans l'histoire, c'est que tu trouveras toujours un anti-MS/anti-DeIcaza pour diffuser le troll de Microsoft & co. Ironique non ?
                  • [^] # Re: Bonne nouvelle

                    Posté par  . Évalué à 5.

                    Mais bin sur Mono il y a des brevets connus qui sont forcement utilise dedans.

                    Linux ca fait deux ans que les VRP Microsoft pretendent cela mais bon meme Linus dit que c'etait des conneries.

                    Tu as oublie un petit detail dans ta liste:

                    Mono est une des applications les plus desinstalle apres l'installation du systeme d'ou le retour en arriere sur f-spot par exemple. Enfin on sait que tu ADORES ce truc moi ce que je vois c'est que cela devait arriver partout et en fait cela disparait de partout, qui parle encore de beagle par exemple, le bureau gnome devait utiliser silverlight mais bon comme il se doit moonlight la version linux n'a jamais reussi a rattraper son retard, maintenant vu que silverlight est en train d'etre abandonne par Microsoft c'est possible qu'ils y arrivent voir carrement qu'ils se retrouvent en charge du code comme pour ironpython, ironruby et F#.
                    • [^] # Re: Bonne nouvelle

                      Posté par  . Évalué à 4.

                      Linux ca fait deux ans que les VRP Microsoft pretendent cela mais bon meme Linus dit que c'etait des conneries.

                      Quand je vois des brevets aussi cons que ceux sur FAT32, je me dis qu'on est à l'abri de rien. Je ne m'oserai pas à prétendre que Linux ne viole aucun brevet.

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

                    • [^] # Re: Bonne nouvelle

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

                      Mais bin sur Mono il y a des brevets connus qui sont forcement utilise dedans.
                      Vas-y, prouve-le : donne nous un lien vers un brevet et le code de Mono associé qui utiliserait le dit brevet.
                      On va voir si tu te fou simplement de la gueule du monde ou si t'es un minimum honnête.

                      PS : je te tire mon chapeau à l'avance, tu viens de faire passer les juristes de RedHat et Novell pour des guignoles simultanément.
                      • [^] # Re: Bonne nouvelle

                        Posté par  . Évalué à 2.

                        PS : je te tire mon chapeau à l'avance, tu viens de faire passer les juristes de RedHat et Novell pour des guignoles simultanément.

                        Ah oui tiens c'est amusant va donc voir pourquoi Moonlight n'est pas inclu dans Fedora et apres on reparle.

                        Pour le reste si il y a des discussions sur separation du code dangereux et celui moins dangereux c'est jsute pour perdre du temps non? Prouve moi par un lien provenant de Microsoft que aucun brevet n'est viole par aucune version de Mono et des softs associe. Je te souhaite bon courage et je decline l'invitation a comparerer les 42 millions de brevets microsoft avec la norme ECMA, la version .Net actuelle (2 ou 3 v ersions depuis non? et cela m'etonnerait bien que Microsoft n'ait depose aucun brevet sur les nouveautes introduite) et Mono.
                        • [^] # Re: Bonne nouvelle

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

                          Ah oui tiens c'est amusant va donc voir pourquoi Moonlight n'est pas inclu dans Fedora et apres on reparle.
                          Moonlight reste un projet à part dans Mono, ça serait bon de ne pas généraliser.

                          Prouve moi par un lien provenant de Microsoft que aucun brevet n'est viole par aucune version de Mono et des softs associe.
                          Tu sais très bien que c'est impossible à prouver gros malin. Et tu sais très bien que j'ai jamais dit que Mono ne violait aucun brevet : j'ai dit que Mono avait un risque, comme tous les autres logiciels libres.

                          Mais en tout cas tu confirmes mon intuition : tu te fou bien de la gueule du monde. Tu affirmes quelque chose (Mono utilise forcement des brevets MS) sans aucune preuve. Ton argumentation est detestable et totalement irrespectueuses des développeurs et utilisateurs de ce logiciel libre.
                          • [^] # Re: Bonne nouvelle

                            Posté par  . Évalué à 0.

                            Ah la la tu as une intuition bien pauvre et de plus tu ne sais pas ni utiliser google ni linuxfr ni lire la FAQ de mono ca fait beaucoup mais bon.

                            http://linuxfr.org/~HAROBED/15586.html

                            si tu fais l'effort de lire et non pas de forcement vouloir utiliser la tactique microsoft de denigrement des interlocuteurs, tu verras qu'il est bien question de BREVET MICROSOFT dans mono.

                            Je vais pas me fatiguer a repondre plus a tes attaques et a rentrer dans les tactiques lobbyste/microsoftienne de on tourne autour du pot pour tenter de noyer le poisson et faire croire que le plafond est en bas et le plancher en haut. Amuses toi bien.
                            • [^] # Re: Bonne nouvelle

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

                              si tu fais l'effort de lire
                              J'ai lu, et ?
                              La politique de Mono est clair : si y'a un brevet qui peut géner, on l'utiliser pas en trouvant un algo alternatif. Si c'est pas possible, on supprime le code en question.

                              Je réitère donc ma demande : montre moi un brevet et un morceau de code de Mono qui violerait le dit brevet.

                              Je vais pas me fatiguer a repondre plus a tes attaques
                              Ou comment avouer que tu n'as strictement aucune preuve de ce que tu prétends. Mais t'as raison, arrête de répondre, c'est tellement ridicule.
                              • [^] # Re: Bonne nouvelle

                                Posté par  . Évalué à 2.

                                La politique de Mono est clair : si y'a un brevet qui peut géner, on l'utiliser pas en trouvant un algo alternatif. Si c'est pas possible, on supprime le code en question.

                                Ok, ca resoud le pb legal (enfin ca montre une bonne volonte tout du moins), par contre si le code en question est supprime, elles font quoi les applis qui en dependent?

                                Note que je suis plutot du cote des "la probabilite d'un proces est tres faible, pas plus eleve qu'avec le kernel en tout cas", mais ca a tendance a me faire peur ce genre d'approche, disons qu'avec le brevet, tu peux payer si t'en as les moyens. La meme si t'as les moyen, tu te retrouves gros jean comme devant.

                                If you can find a host for me that has a friendly parrot, I will be very very glad. If you can find someone who has a friendly parrot I can visit with, that will be nice too.

                                • [^] # Re: Bonne nouvelle

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

                                  mais ca a tendance a me faire peur ce genre d'approche, disons qu'avec le brevet, tu peux payer si t'en as les moyens. La meme si t'as les moyen, tu te retrouves gros jean comme devant.
                                  Oué bah oué, c'est la base même de l'épée de Damoclès des brevets logiciels. Mais Mono est plus concerné qu'un autre, quoiqu'en dise certains.
                                  Donc il faut combattre les brevets logiciels dans leur ensemble et arrêter de taper gratuitement sur un logiciel plus qu'un autre.
                                  • [^] # Re: Bonne nouvelle

                                    Posté par  . Évalué à -1.

                                    T'as pas oublié un "pas" quelque part? Certains t'ont peut être plussé à l'insu de leur plein gré :P
                        • [^] # Re: Bonne nouvelle

                          Posté par  . Évalué à 2.

                          Prouve moi par un lien provenant de Microsoft que aucun brevet n'est viole par aucune version de Mono et des softs associe

                          Et la présomption d'innocence ? Mono n'a rien transgressé, jusqu'à preuve du contraire.

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

                          • [^] # Re: Bonne nouvelle

                            Posté par  . Évalué à 2.

                            La présomption d’innocence est un principe de l’appareil judiciaire. Que je sache, linuxfr n’est pas un tribunal.
                            • [^] # Re: Bonne nouvelle

                              Posté par  . Évalué à 3.

                              Non, mais c'est pas loin. Ici, Mono est littéralement condamné parce qu'il implémente une technologie Microsoft, sans aucun autre argument (même pas technique !).

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

        • [^] # Re: Bonne nouvelle

          Posté par  . Évalué à -3.

          à un moment, faut se prendre par la main, et commencer à vivre sa vie. et oublier boycottnovell. après ça fait des gens bêtes.

          pour preuve: ironique ou pas, écrire "Tant qu'on aura pas brûlé le dernier consultant en propriété intellectuelle" c'est s'exposer à se faire traiter d'à peu près tout ce qu'il est possible d'imaginer.

          et ce, même un vendredi.
      • [^] # Re: Bonne nouvelle

        Posté par  (site web personnel, Mastodon) . Évalué à 5.

        Je rappelle que Mono est libre, faut pas dénigrer le truc uniquement par ce que c'est une implémentation de .NET qui vient de Microsoft.

        Euh...

        http://en.wikipedia.org/wiki/Mono_%28software%29#Mono_and_Mi(...)
        • [^] # Re: Bonne nouvelle

          Posté par  . Évalué à 1.

          Donc je remets la même chose qu'au dessus : pour une application purement Linux qui n'utilise rien de la couche de compatibilité Microsoft, aucun brevet n'est violé.

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

          • [^] # Re: Bonne nouvelle

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

            une application purement Linux

            Mais alors, où est l'intérèt de MONO si on ne peut plus faire du multi-plateforme ?
            • [^] # Re: Bonne nouvelle

              Posté par  . Évalué à 3.

              La qualité du langage et des bibliothèques liées ?

              Envoyé depuis mon lapin.

              • [^] # Re: Bonne nouvelle

                Posté par  . Évalué à 2.

                autant utilise un framework qui n'est pas dans les mains d'une entreprise par consequent et ce n'est pas le choix qui manque dans le libre. Les efforts auraient ete fait pour developper ces alternatives au lieu de tenter de copier le truc Microsoft cela aurait mieux investi a mon avis (qui ne concerne que moi). C'est amusant comme encore une fois cette compagnie n'a pas ete foutu de sortir un logiciel tournant sous linux, en meme temps les technos microsoft elles tournent difficilement sur 2 architectures differentes (et encore meme pas vu que les macs c'est une sorte de pc maintenant)...
                • [^] # Re: Bonne nouvelle

                  Posté par  . Évalué à 2.

                  Je suis d'accord avec toi sur ce point, un langage qui n'est conçu que par une seule entreprise qui n'est pas toujours sympathique, c'est un problème.

                  Mais il faut quand même constater qu'il en est de même avec Java, et que finalement c'est pareil pour la plupart des autres langages. Python, ruby, et compagnie ne sont pas conçus par des consortiums à ce que je sache (mais je peux me tromper).

                  Toujours est-t'il que je trouve en tant que modeste développeur encore débutant dans ces langages (je ne les ai jamais utilisés en milieu professionnel contrairement au python et au C++), je trouve le C# de très bonne facture, et avec de bonnes idées.

                  Envoyé depuis mon lapin.

                  • [^] # Re: Bonne nouvelle

                    Posté par  . Évalué à 5.

                    Pour python c'est une fondation a but non lucratif. Ce qui est tout de meme largement mieux que une entreprise.

                    http://www.python.org/psf/

                    je trouve le C# de très bonne facture, et avec de bonnes idées.

                    Peut etre mais bon ce n'est pas une raison pour faire entrer le loup dans la bergerie.
                    • [^] # Re: Bonne nouvelle

                      Posté par  . Évalué à 3.

                      Pour python c'est une fondation a but non lucratif.

                      Même pas, c'est juste une communauté de développeurs.
                      La PSF sert à financer PyCon et d'autres trucs (ainsi qu'à protéger la « propriété intellectuelle » (sic)), mais elle n'a aucune voix au développement.
                    • [^] # Re: Bonne nouvelle

                      Posté par  . Évalué à -3.

                      Peut etre mais bon ce n'est pas une raison pour faire entrer le loup dans la bergerie.

                      Mais quelle connerie...

                      Quel loup ? C'est un LANGAGE. Il va se passer quoi plus tard ? Le code va se transformer tout seul et effacer ton OS ? Il va subitement emprisonner tes donnees ?

                      Le langage est propre niveau brevets, ainsi que la couche standardisee, utiliser celles-ci ne comporte AUCUN risque, point a la ligne.

                      Utiliser d'autres librairies, ca encourt le meme risque qu'utiliser d'autres librairies dans un autre langage.
                      • [^] # Re: Bonne nouvelle

                        Posté par  . Évalué à 2.

                        Amusant de voir une telle discussion se transformer en troll autour de brevets logiciels et de qualités de langages...

                        Pour rappel, le langage C# a bénéficié d'une mise en œuvre libre avant le langage Java... Second rappel, les brevets logiciels purs ne sont pas applicables en Europe, merci Michel Rocard. C'est gentil de se préoccuper des USA mais je vous promets qu'ils savent le faire tous seuls :)

                        Retour à l'humeur : Que penser du rachat de Novell ? Quelques mois après les déboires de Mandriva, on peut juste se dire que le ciel n'est pas dégagé au-dessus des distributions Linux industrielles, et qu'à ce niveau-là on peut commencer à se poser des questions quand à leur pluralité dans un avenir pas si éloigné...

                        Je pense que Linux ne sera pas mieux vu s'il est représenté par 1 seul éditeur, fût-il RedHat ou Canonical. L'esprit du libre (et ses financements) n'en sortiront pas grandis.
                        • [^] # Re: Bonne nouvelle

                          Posté par  . Évalué à 2.

                          La question n'est pas à mon humble ( très humble ) avis la disparité des distributions qui incluent les mêmes versions des logiciels, la question est de réaliser des distributions qui répondent à des besoins d'utilisation précis.

                          Canonical fait très fort, si Suze ( sic ) correspond réellement à une attente non comblée par RedHat, elle sera remplacée ( je propose Ambassadeur pour rester dans la même veine ) .

                          Mais moi, ce que j'aimerai voir débouler, c'est des gens qui ont envie de bousculer des montagnes, de proposer du GGI+KGI ou autre DirectFB à la Android, ou du Wayland sur des fenêtres virtuelles au dessus d'un plan de travail qui couvrirait tout l'écran, sur un noyau interdisant le freeze système, et de proposer aussi d'autres architectures . Pas de refaire 1000 fois la même gestion de pacquage compatible dans l'esprit avec ce qui a été l'origine: l'arbre des ports FreeBSD .

                          Bon ceci dit, si vous connaissez de bonnes adresses en la matière, j'aimerai tester. :)


                          Ce qui pourrait " pousser " aussi des distributions, c'est d'y intégrer un gros projet type GRC, CAD ou/et compta.

                          Sedullus dux et princeps Lemovicum occiditur

                    • [^] # Re: Bonne nouvelle

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

                      Peut etre mais bon ce n'est pas une raison pour faire entrer le loup dans la bergerie.

                      Voilà, c'est aussi mon avis. Parce qu'après on va se retrouver avec un Gimp en interface MDI. Et
                      peut être bien pire...
            • [^] # Re: Bonne nouvelle

              Posté par  . Évalué à 2.

              Mono permet de faire tourner des appli windows sous linux.
              Les appli linux peuvent être développé en utilisant uniquement la partie sans patent.

              ADO.NET ==> couche donnée par utilisé
              ASP.NET ==> couche graphique web ==> pas utilisé sur les applis linux qui utilise GTK#
              windows.forms ==> couche graphique windows ==> pas utilisé sur les applis linux qui utilise GTK#
              • [^] # Re: Bonne nouvelle

                Posté par  . Évalué à 1.

                Peux tu donner des noms d'applications windows programme avec .Net qui tournent sans changement avec Mono sous linux?

                Cela doit pas etre tres courrant voir quasiment marginal et ils est certains qu'aucune grosse applis .Net ne fonctionne de cette facon la.
                En tout cas pour en citer deux: Paint.Net ca marche pas et Silverlight ca marche pas.


                Donc ca c'est de la com mais la realite est tout autre. Par contre c'est amusant mais une applis python voir C++ avec Qt c'est quasi sans probleme le passage sur une autre plateforme (si cela a ete code correctement et sans se servir des trucs specifics a l'OS naturellement). De meme pour java ou le nombre d'applis multiplateforme qui tournent sans probleme est legion.
                • [^] # Re: Bonne nouvelle

                  Posté par  . Évalué à 2.

                  Donc on en revient au même : si les couches de compat' Microsoft ne servent à rien, Mono ne pose aucun problème ;-)

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

                • [^] # Re: Bonne nouvelle

                  Posté par  . Évalué à 3.

                  > Par contre c'est amusant mais une applis python voir C++ avec Qt c'est quasi sans probleme le passage sur une autre plateforme (si cela a ete code correctement et sans se servir des trucs specifics a l'OS naturellement)
                  Ben pour .Net, c’est exactement pareil.
                  Fait un truc en Gtk#, il tournera sous Linux et Windows sans modification
                  Fait un truc avec les MFC en Python, tu le feras pas tourner sous Linux sans modification
                  • [^] # Re: Bonne nouvelle

                    Posté par  . Évalué à 2.

                    oui donc c'est pas du .Net c'est du mono et donc je ne vois pas l'interet, Le message auquel je repondais disait que les logiciels windows .Net du coup fonctionnaient sous linux et ceci n'a jamais jamais ete vrai.

                    Autant se servir de framework dont la communite dirigent le devenir et non pas cours derriere l'implementation de ref.

                    Python, Qt sont de bons exemple de framework totalement controle par la communite opensource de facon ouverte. Un peu comme ODF, la norme et le travail dessus se fait au vu de tout le monde sans que personne soit avantage par rapport au voisin.
                    • [^] # Re: Bonne nouvelle

                      Posté par  . Évalué à 2.

                      Mono a tout son intérêt, au moins sur le bureau GNOME : l'implémentation de référence ne gère pas GTK, GNOME, Gstreamer, Webkit, FUSE, Zeroconf, etc.

                      Il y a des développeurs dont le langage de référence est C#, on ne va pas les forcer à choisir un autre langage, si ?

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

                      • [^] # Re: Bonne nouvelle

                        Posté par  . Évalué à 3.

                        Sauf que Linux ne se reduit pas (heureusement) a Gnome et si certaines personnes veulent developper en C# c'est leur choix que je ne denigre pas. Ce que je trouve dommage c'est perdre du temps et de l'argent dans des technos que le libre ne controle pas et donc par definition meme d'etre toujours a la ramasses. Ce discours peut tout a fait etre aussi appliquer a Java maintenant.
                        • [^] # Re: Bonne nouvelle

                          Posté par  . Évalué à 4.

                          Le libre ne contrôle pas le C et le C++.
                          Je te conseille donc de faire une campagne de boycott de GCC, Linux, OpenOffice, Gnome, KDE, Apache, etc.
                          Heureusement, il te reste un système d’exploitation complet avec une pléthore d’applications que le libre contrôle entièrement, Emacs. Il te faudra juste une Lisp machine.
                          • [^] # Re: Bonne nouvelle

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

                            Le libre ne contrôle pas le C et le C++.

                            Vu l'importance de GCC, c'est tout comme.

                            Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

                            • [^] # Re: Bonne nouvelle

                              Posté par  . Évalué à 6.

                              Non, ce n’est pas les développeurs de GCC qui définissent le standard C/C++. Si c’était le cas, ils n’auraient pas besoin de faire toute une section « extensions GNU » dans leur manuel.
                              • [^] # Re: Bonne nouvelle

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

                                En tout cas ils ont beaucoup plus d'influence que les devs mono sur Microsoft (qui s'en carre certainement le fondement).

                                Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

                                • [^] # Re: Bonne nouvelle

                                  Posté par  . Évalué à 3.

                                  Oui, ils ont infiniment plus d’influence, dans le sens où 0.000001 / 0 = infini.
                                  Ça ne veut pas dire que cette influence est notable.
                                  Je rappelle que la question n’est pas « qui a la plus grosse » (influence), mais : est-il acceptable pour le libre d’utiliser des technos sur lesquelles il n’a aucune influence notable ?
                                  • [^] # Re: Bonne nouvelle

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

                                    Je pense malheureusement que la question est justement qui a la plus grosse (influence).

                                    Je ne pense pas que le comité qui s'occupe du C++ puisse s'assoir facilement sur GCC alors que Microsoft peut à tout moment sortir une .NET complètement fermée et faire un gros doigt à Mono.

                                    Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

                                    • [^] # Re: Bonne nouvelle

                                      Posté par  . Évalué à 3.

                                      > Je pense malheureusement que la question est justement qui a la plus grosse (influence).
                                      Ben non. Albert_ a dit : on peut pas utiliser C#, parce que le libre le contrôle pas.
                                      Implication fausse, puisque le libre ne contrôle pas non plus C/C++, mais que ça ne semble pas déranger Albert_.
                                      Point.

                                      Arguer pendant des heures sur oui mais le libre contrôle 0.000001% de l’évolution de C++ mais 0% de Mono, excuse moi, mais c’est de l’entubage de drosophiles. Le résultat est le même : si demain Iguaza veut mettre Gtk# dans le standard .Net, il peut pas. Si demain Stallman veut mettre un interpréteur Lisp dans la lib standard du C, ben il peut pas. 0—0, fin de match, rentrez chez vous, ya rien à voir.

                                      > Microsoft peut à tout moment sortir une .NET complètement fermée et faire un gros doigt à Mono.
                                      Version qui devra toujours être compatible avec les versions précédentes.
                                      La vache de gros doigt, j’ai trop peur.
                                      Le fait est là : l’existant .Net/Mono d’aujourd’hui, il est pas fermé, il est pas près de disparaître, et il est suffisamment différent de ce qui existe ailleurs pour intéresser des projets.
                                      • [^] # Re: Bonne nouvelle

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

                                        Les faits sont là :

                                        - c'est Microsoft qui définit l'avenir de .NET et Mono restera éternellement un sous produit à moins d'abandonner la compatibilité et de suivra sa propre voie.
                                        - le C++ est stable depuis des années et GCC est à l'avant garde pour ses évolutions (support de C++1x, Concept GCC...).

                                        Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

                                        • [^] # Re: Bonne nouvelle

                                          Posté par  . Évalué à 3.

                                          Ben non tu t'es trompe dans les faits.

                                          - C# 4 est sorti en Avril 2010, Mono l'a supporte en Septembre soit a peine 5 mois plus tard.
                                          - Que Mono soit un sous-produit de .NET ou pas tout le monde s'en fout, la question est : est-ce qu'il est utile ou pas aux developpeurs, et la la reponse est clairement oui
                                          - C# aussi est stable depuis des annees, et Mono clairement n'est pas en retard
                                          • [^] # Re: Bonne nouvelle

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

                                            Mono lacks a number of features available on the .NET

                                            http://www.mono-project.com/Guidelines:Application_Portabili(...)

                                            Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

                                            • [^] # Re: Bonne nouvelle

                                              Posté par  . Évalué à 4.

                                              Mono, en dehors du fait que C# et la lib peut plaire a certains, n'est de tout de facon qu'un atout pour Microsoft. Si vraiment cette entreprise voulait jouer le jeu de la portabilite j'ose esperer qu'il serait capable de le faire. Qu'il n'existe strictement aucun logiciel de cette boite tournant sous linux de facon native (en particulier avec Mono) montre bien que cela ne sert a rien de faire des efforts pour se rapprocher.

                                              On parle d'une des boites les plus riches du monde, avec le plus d'employe dans le developpement de logiciel et ils ont pas reussi a trouver 2 ou 3 personnes pour faire le port eux meme de quoique ce soit? Et apres il existe des bisounours qui veulent croire que cette boite joue "fair-play"?
                                              • [^] # Re: Bonne nouvelle

                                                Posté par  . Évalué à 3.

                                                Tu mélanges tout.
                                                Un des objectifs de la plateforme .Net (CLR & co) est d’être portable, et en pratique, ça marche.
                                                Par contre, les APIs Microsoft de .Net (Windows Forms) n’ont jamais prétendu avoir cet objectif.

                                                De plus, tu t’obstines à voir Mono comme « un effort de Microsoft pour se rapprocher du LL » (et vice-versa) avec des objectifs stratégiques des deux côtés alors qu’on se tue à te dire qu’on peut aussi tout simplement voir Mono comme une plate-forme de développement comme une autre, avec ses atouts (facile à déployer sous Windows & Linux, pas mal de langages différents, C# assez agréable à utiliser relativement au C++ ou à Java) et ses inconvénients (chiant à déployer sous MacOS X, pas d’API GUI standardisée, pas encore installé de base dans toutes les distributions).
                                              • [^] # Re: Bonne nouvelle

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

                                                Qu'il n'existe strictement aucun logiciel de cette boite tournant sous linux de facon native (en particulier avec Mono) montre bien que cela ne sert a rien de faire des efforts pour se rapprocher.
                                                T'es toujours aussi stupide dans tes affirmations. Après le coup des brevets-que-c-sur-que-mono-violent-mais-que-je-peux-pas-pointer, voici les logiciels qui n'existent pas, strictement, en particulier avec Mono.
                                                C'est tellement comique que Mono diffuse pourtant des logiciels Microsoft, sûrement une preuve qu'ils ne marchent sûrement pas avec Mono :
                                                - ASP.NET MVC
                                                - DLR
                                                - Managed Extensibility Framework (MEF)
                                                - System.Data.Services.Client
                                                D'autres tournent sans problème avec Mono :
                                                - Le compilateur F#
                                                - Le compilateur IronPython
                                                - Le compilateur IronRuby
                                                Voir sont packagés spécifiquement pour Mono :
                                                - Les codecs Windows Media pour Moonlight
                                                Après oui, ce sont essentiellement des logiciels à destination des développeurs et non des produits "grand public", mais c'est assez logique : ces briques n'ont pas de pertinence à être fortement liées à Windows.
                                                D'autres softs sont fournis par MS pour Linux, sans rapport avec Mono :
                                                - Linux Integration Services v2.1 for Windows Server 2008 Hyper-V R2

                                                Et apres il existe des bisounours qui veulent croire que cette boite joue "fair-play"?
                                                Si tu savais le nombre d'entreprise qui ne portent pas leurs logiciels grand public sous Linux, avec leurs 1% de parts de marché sur le desktop, c'est tellement étonnant... MS n'a rien contre les autres OS quand y'a un marché, regarde Mac OS X...
                                                • [^] # Re: Bonne nouvelle

                                                  Posté par  . Évalué à 0.

                                                  Si tu savais le nombre d'entreprise qui ne portent pas leurs logiciels grand public sous Linux, avec leurs 1% de parts de marché sur le desktop, c'est tellement étonnant... MS n'a rien contre les autres OS quand y'a un marché, regarde Mac OS X...

                                                  Ben voyons...

                                                  .Net vise le desktop ? Linux a 1% de part de marché sur les serveurs ?

                                                  Il est impossible d'utiliser un produit MS sans passer à la caisse, même les applications distribuées gratuitement ont besoin au minimum d'un windows pour fonctionner.

                                                  Une version *nix de .Net permettrait de gérer tout le cycle de vie d'un logiciel sans utiliser un seul de leur produit.
                                                  Les éditeurs l'utiliserait de plus en plus, en une décennie il n'y aurait plus aucun intérêt à payer des licences windows, les softs windows only se compteraient sur les doigts de la main, les éditeurs de bloatware installés sur les PCs neufs permettraient aux constructeurs de continuer à se faire payer les installations en économisant les licences windows, fin de la dépendance, fin de leur monopole, que le meilleur gagne.

                                                  Trop cher payé pour tuer java...
                                        • [^] # Re: Bonne nouvelle

                                          Posté par  . Évalué à 3.

                                          > - c'est Microsoft qui définit l'avenir de .NET et Mono restera éternellement un sous produit à moins d'abandonner la compatibilité et de suivra sa propre voie.
                                          Je crois que tu n’as pas compris mon argument.
                                          Aujourd’hui, pour le choix d’une technologie, tu t’intéresses à l’existant hic et nunc. Tu te fous de savoir si les fonctionnalités de la version dans deux ans seront implémentées dans ton implémentation. Ce qui t’intéresse, ce sont les fonctionnalités d’aujourd’hui. Hors, le fait est :
                                          - l’implémentation de Microsoft dans deux ans pourra toujours lancer les applications d’aujourd’hui, parce que c’est dans l’intérêt de Microsoft (je rappelle que Windows 7 est toujours capable de faire tourner les applications Windows 3.11 voire MS-DOS 6). C’est en ce sens que je dis : on se fout de qui contrôle le futur du langage. Donc, si tu ne prends que les fonctionnalités d’aujourd’hui, Mono/.Net est une solution de développement multiplateforme totalement acceptable.
                                          - l’implémentation d’aujourd’hui est aujourd’hui techniquement assez différente de la concurrence, même « totalement libre » (selon le sens assez… particulier des contempteurs de Mono), pour que ces différences techniques surpassent largement les questions d’ordre « politique ».
                                      • [^] # Re: Bonne nouvelle

                                        Posté par  . Évalué à 4.

                                        Toutefois si la forme n’y est pas l’argument reste valable, le C ou le C++ sont des langages qui ont fait leur preuve question compatibilité avec l’ancien. Est-ce qu’on peut en dire autant d’un langage sorti tout droit d’une seule entreprise ? Je veux dire : quelles sont les garanties ?
                                        • [^] # Re: Bonne nouvelle

                                          Posté par  . Évalué à 4.

                                          a) C'est un langage sorti tout droit d'une entreprise dont la reputation niveau compatibilite avec l'ancien n'est plus a faire, personne n'arrive a notre cheville sur ce sujet
                                          b) Ca fait quand meme pas mal d'annees que C# existe maintenant, et il n'y a pas eu de problemes
                                          • [^] # Re: Bonne nouvelle

                                            Posté par  . Évalué à -1.

                                            Mais je ne veux pas de beaux discours, je répète, quelles sont les garanties ? Garanties que Microsoft ne peut pas faire n’importe quoi avec le langage. Qui intervient dans le processus pour décider du futur du langage ? Qui a droit de veto (ou pas) ? Qui code les implémentations de référence ? etc.

                                            Car je suis désolé, mais sur tes deux arguments c’est rien comparé au C, et au passage ton premier devient faux, ça va les chevilles ? Car on parle de langage, pas d’OS, et ça en devient un mensonge étant donné les ténors du secteur.
                                            • [^] # Re: Bonne nouvelle

                                              Posté par  . Évalué à 4.

                                              Garanties ? Mais aucune voyons, tu me donnes un langage qui t'apporte des garanties ? Ca n'existe pas. Avoir une fondation ou autre ne te garantit absolument rien du tout non plus.

                                              Si tu veux un truc similaire au community process de Java, il ya ECMA et ISO, qui valide les specs de C#, ou plusieurs societes et individus participent, ou je le rappelle n'importe qui peut participer hein.

                                              Quand aux implementations de reference, le langage est une spec, personne ne code d'implementation de reference(= qui ferait foi), tout le monde code une implementation, et comme tout langage certaines implementations auront des bugs differents, peut-etre quelques unes seront 100% compliant, etc...

                                              Parce que faut arreter de croire que C a une implementation de reference, il n'en a pas.

                                              Quand au premier, oui merci les chevilles vont bien.
                                              • [^] # Re: Bonne nouvelle

                                                Posté par  . Évalué à 3.

                                                Bon, difficile de répondre à un argumentaire aussi désarticulé, et évite soigneusement les questions. J’en ai profité pour aller faire des recherches Wikipedia, je livre ici ma modeste interprétation des choses.

                                                Quand je parle de garantie je parle bien sûr des processus qui mène à la standardisation du langage. Le standard peut lui-même apporter certaines garanties en fonction des entreprises qui y ont pris part, au passage dire que n’importe qui peut y prendre part est faux : pour l’ISO ce sont les organisations nationales, pour l’ECMA les règles sont un peu plus compliquées et les droits ne sont pas les mêmes pour tout le monde, mais de ce que j’en ai compris ce sont les (grosses) entreprises, et c’est normal, le but de ces organisations est d’émettre des standard industriels et commerciaux !

                                                Je résume ici très grossièrement ce que j’ai compris des lectures Wikipediennes, en comparant avec le C, qui fait l’unanimité, je pense, comme langage de référence. Le C a été développé par 3 gus, des implémentations ont fusé partout toutes plus incompatibles les unes que les autres, quand je parlais d’implémentation de référence je parlais de ça : c’est bien beau d’avoir un langage bien défini, mais si chaque implémentation part dans son sens et devient incompatible avec les autres les spécifications du langage deviennent caduques. La popularité du C vient du fait qu’il a été conçu dès le départ pour une très grande abstraction du matériel sur lequel il tourne, c’est à dire son côté multi-plateforme. L’ISO décide de créer un comité pour mettre au propre une norme, note bien que l’acteur ici est l’ISO. Je n’ai malheureusement pas retrouver qui a participé au comité, ni qui participe à l’heure actuelle aux évolutions (je pense au C99 et au C en préparation). Le C subit une évolution majeure tous les 10 ans, il existe depuis 30 ans. En C il n’existe pas d’implémentation de référence, mais il est populaire et un bon nombre de compilateurs existent sur le marché, ce qui garantit une certaine indépendance vis à vis des spécifications propres et vis à vis d’un compilateur qui commencerait à faire n’importe quoi avec le langage.

                                                À côté de ça tu as le C♯, la version normalisée est la 2.0, Microsoft utilise la 4.0. Je ne sais pas à quel point les deux versions diffèrent mais ça ne présage rien de bon. Le langage est très lié au framework .NET (développé en parallèle, annoncé en même temps), technologie exclusivement Microsoft. Le langage normalisé ISO a 7 ans. Je serai vicieux je te rappellerai un commentaire assez récent que j’ai fait à propos d’ACPI, à ce moment j’avais trouvé comme exemple les documents bureautiques. Pour ceux qui ne voient pas de quoi je parle : il y avait un fil ou un des trolleur avait rapporté l’existence, dont personne ne semble avoir remis en doute la réalité, d’un mail où Microsoft proposait que la norme ACPI soit orientée de telle sorte à favoriser Windows ; on parle régulièrement de problèmes liés à des bugs ACPI, curieusement bien corrigé par Windows : difficile de ne pas faire un parallèle. Il y a aussi un paragraphe sur l’article C♯ de la wikipedia anglaise à propos des accords passés avec Novell, c’est loin d’être simple et forcément donne de quoi se méfier, car populariser des solutions comme Mono c’est aussi donner plus de poids au FUD à propos des brevets. D’un autre côté j’entends bien que cracher sur Mono pour cette raison c’est aussi participer à diffuser ce FUD. Mais si je devais décider je préférerais encore tout simplement éviter de tendre la joue et ne pas utiliser de solutions comme Mono, ou alors se limiter à la version normalisée car elle protège contre l’attaque par brevet si j’en crois Wikipedia, mais on perd l’aspect multi-plateforme et compatibilité avec Microsoft qui utilise la version 4.0. Il existe donc une seule implémentation, qui sera a fortiori une implémentation de référence : celle de Microsoft. Si Microsoft décide de s’écarter franchement de la norme ? Que fait la Mono ? Suivre la norme… bien… mais on perd, encore une fois, toute compatibilité avec la référence, et donc le risque de perdre la très grande majorité des programmes ou développeurs qui se soucient peu de la compatibilité. La position d’Albert, que je comprends parfaitement, est de ne pas prendre, en quelque sorte, de risque en faisant un pari inconsidéré, surtout avec l’historique qu’a l’entreprise, alors qu’il existe de très bonnes solutions libres pour le développement. Cela fait partie d’une stratégie sur le long terme, on dit souvent que le libre manque de direction claire… Mais au final ce seront les utilisateurs qui décideront, souvent pour des raisons bien plus pragmatiques : lancer une machine virtuelle au démarrage de Gnome, c’est lourd, dans tous les sens du terme.

                                                PS : dans le monde du libre l’historique d’une société compte, si elle fait des coups bas les gens le retiennent.

                                                PPS : à propos des chevilles, c’est caractéristique de ton discours hautain, et ça a le mérite de mettre en évidence la culture d’entreprise qui doit régner : « on est les meilleurs ». Forcément quand ça reste entre vous c’est gratifiant de se faire mousser, par contre ici (alias linuxfr) ça passe très mal, et quand je dis ça je pense pouvoir parler au nom de pas mal d’entre nous. Tu réclames que certains d’entre nous se fassent plus consensuels sur leur discours contre Microsoft, mais j’espère que tu te rends compte que dans le genre tu en imposes…

                                                Et désolé pour les fautes, après un commentaire aussi long je n’ai pas envie de me relire…
                                                • [^] # Re: Bonne nouvelle

                                                  Posté par  . Évalué à 3.

                                                  Le standard peut lui-même apporter certaines garanties en fonction des entreprises qui y ont pris part, au passage dire que n’importe qui peut y prendre part est faux : pour l’ISO ce sont les organisations nationales, pour l’ECMA les règles sont un peu plus compliquées et les droits ne sont pas les mêmes pour tout le monde, mais de ce que j’en ai compris ce sont les (grosses) entreprises, et c’est normal, le but de ces organisations est d’émettre des standard industriels et commerciaux !

                                                  Non, ECMA accepte les petites et grandes entreprises, ainsi que les organisations a but non-lucratif, qui y ont les memes droits que les societes, cf. http://www.ecma-international.org/memento/Ecmabylaws.htm

                                                  La popularité du C vient du fait qu’il a été conçu dès le départ pour une très grande abstraction du matériel sur lequel il tourne, c’est à dire son côté multi-plateforme.

                                                  Tu m'excuseras mais non pas du tout, le C n'a pas grand-chose de multi-plateforme, son avantage est justement d'etre tres proche du materiel. C'est aussi son desavantage d'ailleurs, il l'est trop, un simple pointeur par exemple change de taille selon le systeme, le cote big/little endian n'est pas du tout gere, etc...

                                                  À côté de ça tu as le C♯, la version normalisée est la 2.0, Microsoft utilise la 4.0.

                                                  Non, la version normalisee est la 3.0 , la 4.0 est sortie il y a quelque mois donc ca va venir.

                                                  Le langage est très lié au framework .NET (développé en parallèle, annoncé en même temps), technologie exclusivement Microsoft.

                                                  Il y est lie en quoi ? A part avec la base de la base du framework en rien du tout, et la base du framework est standardisee aussi.

                                                  Pour ceux qui ne voient pas de quoi je parle : il y avait un fil ou un des trolleur avait rapporté l’existence, dont personne ne semble avoir remis en doute la réalité, d’un mail où Microsoft proposait que la norme ACPI soit orientée de telle sorte à favoriser Windows ; on parle régulièrement de problèmes liés à des bugs ACPI, curieusement bien corrigé par Windows : difficile de ne pas faire un parallèle

                                                  Faudrait penser a comprendre le probleme : MS donne un compilo ACPI pour Windows, ce compilo ne gere que Windows, car MS ne s'interesse qu'a Windows. Evidemment que les constructeurs qui utilisent ce compilo risquent de se retrouver avec du code qui ne fait pas tourner Linux, a eux d'utiliser un compilo fait pour etre multi-OS.

                                                  Il y a aussi un paragraphe sur l’article C♯ de la wikipedia anglaise à propos des accords passés avec Novell, c’est loin d’être simple et forcément donne de quoi se méfier, car populariser des solutions comme Mono c’est aussi donner plus de poids au FUD à propos des brevets.

                                                  Il n'y a aucun FUD la dedans, Mono est couvert par une promesse de MS sur les brevets, il n'y a donc absolument _AUCUN_ risque, que ce soit demain ou dans 20 ans.

                                                  Mais si je devais décider je préférerais encore tout simplement éviter de tendre la joue et ne pas utiliser de solutions comme Mono, ou alors se limiter à la version normalisée car elle protège contre l’attaque par brevet si j’en crois Wikipedia, mais on perd l’aspect multi-plateforme et compatibilité avec Microsoft qui utilise la version 4.0

                                                  T'as toujours pas compris le probleme.
                                                  C#, que ce soit 1.0, 2.0, 3.0 ou 4.0 est propre niveau brevets et il n'y a aucun risque.
                                                  Le risque, c'est quand t'utilises une reimplementation d'une librairie MS qui ne fait pas partie du framework standardise, genre WindowsForms.
                                                  Tu peux tout a fait ecrire un tas de softs en C# 4.0 avec Mono qui sont garantis 100% sans aucun risque niveau brevets MS, faut simplement suivre le standard qui te dit ce qui est standardise et ce qui ne l'est pas (ADO.net, ASP.Net, Windows Forms,..)

                                                  Il existe donc une seule implémentation, qui sera a fortiori une implémentation de référence : celle de Microsoft.

                                                  Non il y en a au moins 2 vu que Mono implemente C# 4 en toute legalite.

                                                  Si Microsoft décide de s’écarter franchement de la norme ? Que fait la Mono ? Suivre la norme… bien… mais on perd, encore une fois, toute compatibilité avec la référence, et donc le risque de perdre la très grande majorité des programmes ou développeurs qui se soucient peu de la compatibilité.

                                                  Et pourquoi est-ce que Mono suivrait ? Il y a une loi qui dit que Mono doit suivre comme un petit chien ?

                                                  PS : dans le monde du libre l’historique d’une société compte, si elle fait des coups bas les gens le retiennent.

                                                  Pas vraiment non, ils ont tendance a retenir ce qui leur plait et oublier le reste(je parles des fans, les devs ont plus d'experience et mettent de l'eau dans leur vin)

                                                  à propos des chevilles, c’est caractéristique de ton discours hautain, et ça a le mérite de mettre en évidence la culture d’entreprise qui doit régner : « on est les meilleurs ». Forcément quand ça reste entre vous c’est gratifiant de se faire mousser, par contre ici (alias linuxfr) ça passe très mal, et quand je dis ça je pense pouvoir parler au nom de pas mal d’entre nous. Tu réclames que certains d’entre nous se fassent plus consensuels sur leur discours contre Microsoft, mais j’espère que tu te rends compte que dans le genre tu en imposes…

                                                  Je vais pas le cacher, je trouves que sur certains aspects MS est loin devant les autres, il y a aussi des aspects ou on est derriere c'est evident, mais je vais pas me forcer a cacher les bons cotes pour faire plaisir aux gens ici, c'est pas vraiment ma nature.
                                                  • [^] # Re: Bonne nouvelle

                                                    Posté par  . Évalué à 4.

                                                    Est-ce que tu as seulement lu le lien que tu donnes sur ECMA ? Je vais t’aider et citer le passage. « 4.2 Decisions on acceptance shall be made by the General Assembly with a two thirds majority of all the ordinary members. » Tu continues sur le site, et tu as la liste des membres de l’Assemblée générale : 18 noms, de grosses entreprises. Pour entrer il te faut le soutien de 12 des ces entreprises. Après tu peux avoir un droit de regard sans faire partie des décisions, mais on retrouve là encore que des grands noms. Je regarde les faits : c’est un club très petit, ne me dis pas que n’importe qui peut y entrer.

                                                    Le C est multi-plateforme, dire le contraire n’est que l’aboutissement d’années de propagande (je soupçonne Java). Quand tu codes en C tu n’as pas a savoir si t’es en little ou big endian, ni la taille de tes pointeurs, ce sont des représentations internes de la machine et le C permet justement de s’en affranchir ! Quand j’écris un int, et durant tout le code, je me fiche des détails techniques de représentation des nombres : endianness, taille des données à la précision numérique près, etc. Quand j’écris un code ANSI C il doit tourner et rendre le même résultat quelque soit la machine le supportant (à la précision numérique près), la force du C est très précisément d’abstraire ces problèmes de représentation interne. Je soupçonne que tu mélanges avec la portabilité des données, binaires, produites et enregistrées sur disque, ce qui n’a rien à voir avec la portabilité du code. Mais ce problème explose au développeur inattentif très précisément parce que le code C a abstrait cette représentation.

                                                    Tu dis « la version normalisée est la 3.0 », j’attends tes sources, parce que ce n’est pas ce que dit Wikipedia, du coup je suis allé voir la liste des standard ECMA : C# 4ème édition : juin 2006, selon Wikipedia la sortie de la version 3.0 du langage chez Microsoft date d’Août 2007.

                                                    Concernant ACPI, au contraire j’ai parfaitement compris le problème, je l’ai posé en terme d’implémentation de référence : si l’implémentation de référence ne respecte pas le standard, ce dernier ne sert plus à rien. Je fais le parallèle avec la situation de Mono vs. l’implémentation de Microsoft.

                                                    Bien sûr qu’il y a un FUD à propos des brevets, demande à Albert, à propos de Linux, à propos de l’attaque contre Tomtom sur le Fat32, tout ceci y participe, utiliser des technologies de chez Microsoft est susceptible de l’alimenter. Pas sur le langage en lui-même : mais ça je l’ai dit, tu n’as juste pas lu, la partie standardisée ou couverte par des accords unilatéraux (ie. Microsoft envers quiconque, quiconque étant égal à all et différent des non-profit ou autre OSS) n’a pas à craindre de brevets. Mais il est difficile de faire la part des choses et de relever ce qui est couvert par les brevets de ce qui ne l’est pas. C’est déjà assez difficile concernant le noyau… c’est une guerre de communication : utiliser des techno. de chez Microsoft c’est donner de la force au FUD.

                                                    « Non il y en a au moins 2 vu que Mono implemente C# 4 en toute legalite. » Mono est développé par Novell qui a des accords spécifiques avec Microsoft. Qu’en est-il du reste de l’éco-système, libre, non-libre, commerciaux, etc., qui utiliserait Mono, implémenterait une lib. avec des fonctionnalités proches d’une lib. non couverte par les accords, tout ceci sur une techno. spécifiquement Microsoft, tu vas me dire qu’il n’existe aucun risque de tomber sur une solution proche de ce qu’à utiliser, et breveté, Microsoft ? Le risque est àmha plus grand que de partir from scratch.

                                                    Enfin je n’ai jamais dit que Mono devrait suivre à fortiori le standard « comme un petit chien ». Dans ce cas il suit l’implémentation de référence : retour à la case départ, ce sera du Microsoft, ça ne sera plus couvert par un standard, donc soumis à des attaques ou FUD sur les brevets. Ou alors Mono suit sa propre voie, redéfinit un langage à lui, etc., mais on perd toute compatibilité. Je ne sais pas pourquoi je me répète, tu ne vas pas plus lire que la première fois.
                                                    • [^] # Re: Bonne nouvelle

                                                      Posté par  . Évalué à 1.

                                                      Est-ce que tu as seulement lu le lien que tu donnes sur ECMA ? Je vais t’aider et citer le passage. « 4.2 Decisions on acceptance shall be made by the General Assembly with a two thirds majority of all the ordinary members. » Tu continues sur le site, et tu as la liste des membres de l’Assemblée générale : 18 noms, de grosses entreprises. Pour entrer il te faut le soutien de 12 des ces entreprises

                                                      N'importe quoi !

                                                      http://www.ecma-international.org/memento/NFP.htm
                                                      http://www.ecma-international.org/memento/SPC.htm
                                                      http://www.ecma-international.org/memento/SME.htm

                                                      Toutes ces entreprises/fondations ne sont pas des grosses entreprises, et ils sont membres de l'assemblee generale.

                                                      Le C est multi-plateforme, dire le contraire n’est que l’aboutissement d’années de propagande (je soupçonne Java). Quand tu codes en C tu n’as pas a savoir si t’es en little ou big endian, ni la taille de tes pointeurs, ce sont des représentations internes de la machine et le C permet justement de s’en affranchir ! Quand j’écris un int, et durant tout le code, je me fiche des détails techniques de représentation des nombres : endianness, taille des données à la précision numérique près, etc. Quand j’écris un code ANSI C il doit tourner et rendre le même résultat quelque soit la machine le supportant (à la précision numérique près), la force du C est très précisément d’abstraire ces problèmes de représentation interne.

                                                      Ben va t'amuser a prendre du code qui tourne sur une machine A et porte le sur une machine B, tu vas comprendre, si tu ne fais pas extremement attention, tu te feras bouffer.
                                                      Au hasard le fait que ta taille de pointeur est passee de 4 a 8 bytes, que ton alignement des allocations a change, que le systeme A lance une exception en cas d'acces non-aligne alors que le systeme B ne le fait pas, ...
                                                      Visiblement tu n'a jamais eu a faire un portage.

                                                      Tu dis « la version normalisée est la 3.0 », j’attends tes sources, parce que ce n’est pas ce que dit Wikipedia, du coup je suis allé voir la liste des standard ECMA : C# 4ème édition : juin 2006, selon Wikipedia la sortie de la version 3.0 du langage chez Microsoft date d’Août 2007.

                                                      Et ? Ca n'empeche pas de normaliser le langage avant la sortie de Visual Studio hein...

                                                      http://msdn.microsoft.com/en-us/netframework/aa569283.aspx

                                                      In June 2005, the General Assembly of the international standardization organization Ecma approved edition 3 of the C# Language and the Common Language Infrastructure (CLI) specifications, as updated Ecma-334 and Ecma-335, respectively (see press release).

                                                      Concernant ACPI, au contraire j’ai parfaitement compris le problème, je l’ai posé en terme d’implémentation de référence : si l’implémentation de référence ne respecte pas le standard, ce dernier ne sert plus à rien. Je fais le parallèle avec la situation de Mono vs. l’implémentation de Microsoft.

                                                      Mais qui te parle d'implementation de reference ? Qui a designe le compilo de MS comme implementation de reference ? Ils disent clairement que ce compilo est la pour le support de Windows, pas autre chose.
                                                      T'utilises le compilo Intel, Windows tourne et Linux tourne, c'est pas un probleme. Et va pas me dire qu'Intel est un nain hein, ils font partie des createurs d'ACPI au meme titre que MS.

                                                      Mais il est difficile de faire la part des choses et de relever ce qui est couvert par les brevets de ce qui ne l’est pas. C’est déjà assez difficile concernant le noyau… c’est une guerre de communication : utiliser des techno. de chez Microsoft c’est donner de la force au FUD.

                                                      Non, cela n'a ABSOLUMENT RIEN de difficile : http://port25.technet.com/archive/2009/07/06/the-ecma-c-and-(...)

                                                      C'est tres clair, tout ce qui est dans la spec ECMA est protege contre les brevets, point a la ligne.

                                                      Mono est développé par Novell qui a des accords spécifiques avec Microsoft. Qu’en est-il du reste de l’éco-système, libre, non-libre, commerciaux, etc., qui utiliserait Mono, implémenterait une lib. avec des fonctionnalités proches d’une lib. non couverte par les accords, tout ceci sur une techno. spécifiquement Microsoft, tu vas me dire qu’il n’existe aucun risque de tomber sur une solution proche de ce qu’à utiliser, et breveté, Microsoft ? Le risque est àmha plus grand que de partir from scratch.

                                                      Et dis-moi, quel est le risque si tu implementes DirectX ou autre lib MS sous Linux ? Identique a implementer une lib MS sous Mono.
                                                      Tu vas me faire croire que par hasard tu vas reimplementer une lib MS sans t'en rendre compte ? Tu te fiches de moi ?

                                                      Dans ce cas il suit l’implémentation de référence : retour à la case départ, ce sera du Microsoft, ça ne sera plus couvert par un standard, donc soumis à des attaques ou FUD sur les brevets. Ou alors Mono suit sa propre voie, redéfinit un langage à lui, etc., mais on perd toute compatibilité. Je ne sais pas pourquoi je me répète, tu ne vas pas plus lire que la première fois.

                                                      N'importe quoi, tu m'expliques pourquoi il ne peut pas suivre LA SPEC plutot que l'implementation MS ?
                                                      Parce que tu vois, c'est ce qu'il fait, il implemente des elements de la spec que meme MS n'implemente pas.
                                                      • [^] # Re: Bonne nouvelle

                                                        Posté par  . Évalué à 4.

                                                        Pour ECMA, les membres que tu cites ne font pas parti de l’assemblée générale, qui, seule, vote pour ou contre l’inclusion des nouveaux membres à la majorité des 2/3 et pour la publication des normes (dans le menu présentation il y a un pdf, je l’ai un peu parcouru). Les membres que tu cites ont des droits dans les comités techniques, c’est-à-dire l’élaboration des normes. Et en tout il n’y a que 60 entreprises regroupées sous ECMA, toutes ont nécessairement été acceptées par l’AG (c.-à-d. les 18 entreprises pré-citées).

                                                        Le C est portable, oui, il a été conçu pour ; Wikipedia le dit, mes professeurs me l’ont toujours dit, et je le constate tous les jours : je n’ai jamais eu à porter un code, oui, parce que précisément le C est portable, tous les jours j’utilise le même code sur des machines indifféremment 32 ou 64 bits. Que tu puisses faire des choses non-portables en C démontre juste que ce n’est pas un langage neuneu-proof, mais pas portable : non ; Malloc t’assure l’alignement des données, tu les dé-s-alignes : c’est ton problème.

                                                        Pour revenir sur le cœur du sujet : je ne crois pas que le numéro du standard correspond à la version du langage, en tout cas les fonctionnalités qu’apportent la version du standard ECMA nº4, si j’en crois ton lien, correspondent aux fonctionnalités du langage en version 2 de chez Microsoft, si j’en crois Wikipedia. La liste des fonctionnalités dans les version 3 et 4 sont donc non normalisées, avec les conséquences que j’ai exposées.

                                                        Il reste la question de différencier de ce qui est couvert ou pas, si c’est clair pour toi, tant mieux. Mais je le répète tout ceci est une guerre de communication (c’est le principe du FUD), pour aller vérifier que telle implémentation d’un langage est conforme à telle standard, et donc non soumis à attaque par brevets, il faut avoir des compétences au seins de l’entreprise, et pas des moindres : tout ça pour vérifier qu’on peut utiliser Tomboy (je force le trait) ? Bref s’il faut parcourir une spécification d’un langage et son implémentation pour vérifier les choses, ça signifie que c’est loin d’être simple.

                                                        ACPI était un exemple pour mon autre argument : on a d’une part le problème du FUD sur les brevets, d’autre part le problème de la main-mise sur le langage, que ce soit au niveau institutionnel (standard, qui sont plus une solution qu’un problème pour apporter quelques garanties), ou que ce soit au niveau pratique. Et là ACPI montre que grâce à une implémentation de référence, qui n’est rien d’autre que le standard de facto (hors toute considération de l’existence d’un standard institutionnel), Microsoft a su tourner la situation à son avantage. Il est difficile de croire qu’ils n’en feront pas de même pour le langage dont il est question ici.

                                                        Enfin vient l’utilisation de techno. Microsoft, oui, le risque « par hasard » n’est pas si petit que ça une fois que tu t’es donné l’objectif de : ré-implémenter avec une technologie Microsoft, avoir une API proche de la lib. Microsoft, etc. Tu offres mécaniquement plus de possibilité de tomber sur le coup d’un brevet. Sans compter que tu as toujours ce problème de communication et de FUD qui vient : cela donne plus de poids à ce dernier pour faire croire qu’il y a lieu de s’inquiéter.
                                                        • [^] # Re: Bonne nouvelle

                                                          Posté par  . Évalué à 1.

                                                          Pour ECMA, les membres que tu cites ne font pas parti de l’assemblée générale, qui, seule, vote pour ou contre l’inclusion des nouveaux membres à la majorité des 2/3 et pour la publication des normes (dans le menu présentation il y a un pdf, je l’ai un peu parcouru). Les membres que tu cites ont des droits dans les comités techniques, c’est-à-dire l’élaboration des normes. Et en tout il n’y a que 60 entreprises regroupées sous ECMA, toutes ont nécessairement été acceptées par l’AG (c.-à-d. les 18 entreprises pré-citées).

                                                          En fait on avait tous les 2 tort, voila les membres de l'AG : http://www.ecma-international.org/memento/GA.htm

                                                          Clairement il y a plus que les 18 grosses societes, y compris des petites societes, par contre il semble ne pas y avoir de fondations a but non lucratif.

                                                          Le C est portable, oui, il a été conçu pour ; Wikipedia le dit, mes professeurs me l’ont toujours dit, et je le constate tous les jours : je n’ai jamais eu à porter un code, oui, parce que précisément le C est portable, tous les jours j’utilise le même code sur des machines indifféremment 32 ou 64 bits. Que tu puisses faire des choses non-portables en C démontre juste que ce n’est pas un langage neuneu-proof, mais pas portable : non ; Malloc t’assure l’alignement des données, tu les dé-s-alignes : c’est ton problème.

                                                          Non desole, etre un langage portable signifie JUSTEMENT que tu n'es pas sense faire des pieds et des mains pour t'assurer que le code est portable.
                                                          Les problemes d'alignement dans les structures, de la definition de ce qu'est un int tout simplement (peut changer de taille d'une machine a l'autre, vive la gestion des overflows), etc... font que c'est un langage CHIANT pour le multiplateforme.

                                                          Pour revenir sur le cœur du sujet : je ne crois pas que le numéro du standard correspond à la version du langage, en tout cas les fonctionnalités qu’apportent la version du standard ECMA nº4, si j’en crois ton lien, correspondent aux fonctionnalités du langage en version 2 de chez Microsoft, si j’en crois Wikipedia. La liste des fonctionnalités dans les version 3 et 4 sont donc non normalisées, avec les conséquences que j’ai exposées.

                                                          En effet tu avais raison, c'est la 3eme edition, mais elle correspond a C# 2.0, tu noteras par contre que sur http://msdn.microsoft.com/en-us/netframework/aa569283.aspx ils donnent les working drafts pour la 5eme edition du standard, ils y travaillent donc.

                                                          Mais je le répète tout ceci est une guerre de communication (c’est le principe du FUD), pour aller vérifier que telle implémentation d’un langage est conforme à telle standard, et donc non soumis à attaque par brevets, il faut avoir des compétences au seins de l’entreprise, et pas des moindres : tout ça pour vérifier qu’on peut utiliser Tomboy (je force le trait) ? Bref s’il faut parcourir une spécification d’un langage et son implémentation pour vérifier les choses, ça signifie que c’est loin d’être simple.

                                                          Arf super, et c'est EXACTEMENT la meme choes pour 3533 autre standards, tu vas arreter d'utiliser les codecs video, audio, les fontes etc... alors ?

                                                          là ACPI montre que grâce à une implémentation de référence, qui n’est rien d’autre que le standard de facto (hors toute considération de l’existence d’un standard institutionnel), Microsoft a su tourner la situation à son avantage. Il est difficile de croire qu’ils n’en feront pas de même pour le langage dont il est question ici.

                                                          Tu m'expliques pourquoi tu rejettes sur MS le fait que certains constructeurs prennent son compilo, qui est clairement labele comme etant fait pour Windows, plutot qu'un compilo ACPI tel que celui d'Intel ?

                                                          Enfin vient l’utilisation de techno. Microsoft, oui, le risque « par hasard » n’est pas si petit que ça une fois que tu t’es donné l’objectif de : ré-implémenter avec une technologie Microsoft, avoir une API proche de la lib. Microsoft, etc. Tu offres mécaniquement plus de possibilité de tomber sur le coup d’un brevet. Sans compter que tu as toujours ce problème de communication et de FUD qui vient : cela donne plus de poids à ce dernier pour faire croire qu’il y a lieu de s’inquiéter.

                                                          Oui bien sur, par hasard tu vas reimplementer asp.net ou ado.net , sans t'en rendre compte ! Un peu de serieux stp...
                                                        • [^] # Re: Bonne nouvelle

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

                                                          Le C est portable, oui, il a été conçu pour ; Wikipedia le dit, mes professeurs me l’ont toujours dit, et je le constate tous les jours
                                                          Ca c'est la théorie. Pourtant, moi aussi je vais citer Wikipedia, à la rubrique inconvénients :
                                                          "il est difficile d'écrire des programmes portables car le comportement exact des exécutables dépend de l'ordinateur cible ;"
                                                          Ca c'est la vraie vie.

                                                          Un langage qui laisse le choix à l'implémentation de la taille d'un "int", c'est clairement une lacune qui fait qu'un code, bien que respectant la norme ANSI C, ne sera pas portable. Et c'est ce qui se passe en pratique : suivant l'architecture cible, la taille d'un int diffère.
                                                          Cet exemple suffit à montrer, que bien qu'étant "relativement" portable, la norme ANSI C est loin d'être la panacée niveau portabilité.

                                                          Si je reprends toujours ta même source, Wikipedia, il y a même une rubrique dédiée aux trucs mal définis qui font qu'un code écrit en ANSI C n'est pas forcement portable, le résultat dépendant des choix d'implémentation :
                                                          http://fr.wikipedia.org/wiki/C_(langage)#Comportements_mal_d(...)

                                                          Bref, ne pas confondre la théorie, les objectifs affichés, les blablas de chercheurs et la vraie vie.
                                                          • [^] # Re: Bonne nouvelle

                                                            Posté par  . Évalué à 3.

                                                            Bien, tu as juste prouvé que ceux qui ne suivent pas la norme ANSI ont des problème de portabilité.

                                                            Je crois qu’il y a un problème de définition : coder en ANSI veut dire respecter la norme et ne pas faire de suppositions sur les comportements indéfinis de la norme.

                                                            Taille des int ⇒ tout un tas de constante à chercher dans un include (dont j’ai oublié le nom), dans le cas où on sait que ce sera problématique.
                                                            / d’entiers négatifs ⇒ Répètes après moi : « La division d’entiers en C est une division euclidienne. » Un fois que tu as compris ça tu n’as plus jamais de problème avec les divisions d’entiers, quelque soit le langage. C’est tout simplement magique…¹
                                                            Taille des pointeurs ⇒ sizeof est ton ami.

                                                            Va donc sur l’article anglais, la phrase est assez éloquente :
                                                            « The reason some behavior has been left undefined is to allow compilers for a wide variety of instruction set architectures to generate more efficient executable code for well-defined behavior, which was deemed important for C's primary role as a systems implementation language; thus C makes it the programmer's responsibility to avoid undefined behavior, possibly using tools to find parts of a program whose behavior is undefined. Examples of undefined behavior are:

                                                            * accessing outside the bounds of an array
                                                            * overflowing a signed integer
                                                            * reaching the end of a non-void function without finding a return statement, when the return value is used
                                                            * reading the value of a variable before initializing it »

                                                            Les comportement indéfinis sont précisément là pour laisser champ libre à l’implémentation en fonction de l’architecture cible. Et pour enfoncer le clou :
                                                            « These operations are all programming errors that could occur using many programming languages; C draws criticism because its standard explicitly identifies numerous cases of undefined behavior, including some where the behavior could have been made well defined, and does not specify any run-time error handling mechanism. » C’est-il pas beau ?

                                                            Pour la route : « man gcc », [/], « -ansi », « -pedantic », et surtout retourner sur les bancs de l’école. On ne peut pas dire que je pisse du C à longueur de journée, mais je connais quand même les bases.

                                                            Et, je crois que ça vient de C99, s’il y a quelqu’un pour confirmer…, on a accès à des types à la taille prédéfinie.

                                                            ¹ D’une part, la division euclidienne n’est bien définie que pour les entiers naturels (c.-à-d. positifs), d’autre part, la blague avec l’arrondi à l’entier inférieur n’en est plus une.
                                                            • [^] # Re: Bonne nouvelle

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

                                                              coder en ANSI veut dire respecter la norme et ne pas faire de suppositions sur les comportements indéfinis de la norme.
                                                              Si tu veux utiliser des int, va pourtant bien falloir que tu fasses une supposition sur le comportement du compilateur... Si tu ne veux pas faire de supposition, la seule alternative qu'il te reste, c'est de ne pas utiliser le type int.
                                                              Tu peux aussi t'amuser à faire des tests à coup de #ifdef : pour que ton code deviennt "portable" : c'est jamais qu'un aveu de non portabilité : tu écris du code spécifiques dans chaque branche de ton if.

                                                              Les comportement indéfinis sont précisément là pour laisser champ libre à l’implémentation en fonction de l’architecture cible.
                                                              On est d'accord, y'a une bonne raison : c'est pour des questions de perf/optimisation. Mais il n'en reste pas moins que le code devient non portable puisqu'avec un comportement potentiellement différent d'une architecture à l'autre.
                                                              D'ailleur la phrase que tu cites est effectivement éloquente : grosso modo il est de la responsabilité du programmeur de s'assurer que son code est portable. Ce qui montre bien que la norme ne l'assure pas.
                                                              CQFD.

                                                              On ne peut pas dire que je pisse du C à longueur de journée, mais je connais quand même les bases.
                                                              Le problème, c'est que t'as visiblement jamais bosser sur un vrai projet en C : la vraie vie, c'est que t'as intérêt de faire gaffe quand tu codes en C si tu veux qu'il soit portable, et t'as sacrément besoin de vérifier. T'appelles ça des "erreurs" de programmation si tu veux, le fait est que le compilateur ne t'offre aucune garantie que le code que tu pondes soit portable, et pour cause, la norme l'oblige à faire un choix qui ne sera pas le même que celui du voisin.

                                                              D'ailleurs, quelque chose qui montre bien que la norme ANSI C n'est pas un garant de portabilité (même si son respect met le code sur la bonne voie), c'est le nombre de "guide" pour le programmeur afin qu'il fasse attention à la portabilité du code qu'il écrit :
                                                              "Guide pour la portabilité" : http://docs.hp.com/en/B3901-90005/ch05s02.html
                                                              http://serghei.net/docs/programming/autobook-1.1/writing20po(...) (citation rigolote : "The C language makes it easy to write non-portable code")
                                                              Le mythe de la portabilité du C : http://spinning-yarns.org/blog/?p=451
                                                              http://www.psgd.org/paul/docs/cstyle/cstyle16.htm (avec ma préférée : "C combines the power of assembler with the portability of assembler. " )
                                                              http://unixwiz.net/about/porting.html ( "Ultimately, most software porters created portability macros that allowed the use of many of these features in code that could be straight K&R or ANSI.")

                                                              Voilà la vraie vie de nombreuses personnes. Rien à voir visiblement avec ton expérience personnelle.
                                                              Quand tu codes en Java ou en C#, t'es pas en train de poser des questions sur le fait que ton code soit portable ou non en fonction de l'architecture matérielle, tu te demandes juste si les libs que tu utilises sont portables (cad s'appui sur du code natif portable ou non) : ce sont des beaucoup plus portables que le ANSI C.
                                                              • [^] # Re: Bonne nouvelle

                                                                Posté par  . Évalué à 2.

                                                                Ok, vite fait .

                                                                int a une taille minimal : 16 bits, quand tu risques de dépasser, comme je l’ai dit, les constantes sont définies, par exemple si tu additionnes deux int il faut faire attention que les deux soit < INT_MAX / 2 par exemple (je ne me rappelle plus le nom exacte de la constante). Pareil pour la multiplication : il faut vérifier que tu es inférieur à la racine. Au passage je crois que c’est pareil pour le java, en C# j’en sais rien et je m’en tape. Et, mis à part si le langage peut manipuler des entiers de taille arbitraire, il faut faire attention à la taille des int, toujours, sinon ton code va t’exploser à la gueule tôt ou tard.

                                                                Ne pas accepter d’utiliser une variable nommée INT_MAX (ou que sais-je) en lieu et place d’un nombre codé en dur dans ton code est au mieux du foutage de gueule, au pire de l’incompétence.
                                                                • [^] # Re: Bonne nouvelle

                                                                  Posté par  . Évalué à 1.

                                                                  Ah mais si c'etait si simple hein ?

                                                                  Un entier de 16bit, ca fait 65536 valeurs, un entier de 32bits plus de 4 milliards.

                                                                  Alors, ton soft il passe de l'un a l'autre, tu crois que c'est sans effet de bord ?

                                                                  Genre ton soft qui faisait des allocations de 64Ko, maintenant risque d'en faire de 4Go, ou autre difference, etc...

                                                                  Faut se reveiller un peu, porter du code non-trivial en C, c'est pas tout simple.

                                                                  Quand a la #define INT_MAX codee en dur, tu appelles ca de l'incompetence, moi j'appelles ca vivre dans la vraie vie ou 95% des etudiants sortis d'universite ne savent pas que INT_MAX existe.
                                                                  • [^] # Re: Bonne nouvelle

                                                                    Posté par  . Évalué à 3.

                                                                    Mais… mais… merde à la fin ! Tu le fais exprès, c’est pas possible, tu veux troller c’est ça ?

                                                                    en:C_standard_library
                                                                    en:limits.h

                                                                    Et tu as le même problème en Java ! Faut vérifier que tu ne dépasses pas la limite. La seule différence est qu’en Java le code gruik avec le chiffre en dur est accepté.

                                                                    95 % ? T’es optimiste ! :p
                                                                    • [^] # Re: Bonne nouvelle

                                                                      Posté par  . Évalué à 0.

                                                                      Non je parles de realite.

                                                                      Amuses toi avec un truc du genre :

                                                                      int* MyArray=malloc(INT_MAX); --> alloue 32Ko sur une machine avec entiers de 16bit, ce qui est tout a fait acceptable.

                                                                      Maintenant va passer ca sur une machine avec entiers en 32bit et prend toi l'allocation de 2Go dans la tronche, ca va etre drole...

                                                                      Quand a Java, si j'en crois http://download.oracle.com/javase/tutorial/java/nutsandbolts(...) c'est tres clair, un int est 32bit, quel que soit l'OS du dessous (normal vu que la JVM donne une plateforme abstraite identique partout).
                                                                      • [^] # Re: Bonne nouvelle

                                                                        Posté par  . Évalué à 3.

                                                                        « int* MyArray=malloc(INT_MAX); --> alloue 32Ko sur une machine avec entiers de 16bit [...] Quand a Java »

                                                                        ⇒ Fortune !
                                                                        • [^] # Re: Bonne nouvelle

                                                                          Posté par  . Évalué à 0.

                                                                          Jolie facon d'evader la conversation...
                                                                          • [^] # Re: Bonne nouvelle

                                                                            Posté par  . Évalué à 8.

                                                                            Ha, si malloc(INT_MAX) c’est quelque chose de parfaitement standard chez vous, ça explique certaines choses…
                                                                            • [^] # Re: Bonne nouvelle

                                                                              Posté par  . Évalué à 1.

                                                                              Sur un systeme avec entiers 16bits ca a son sens, tu veux allouer un tableau de la taille maximale (une entree pour chaque index possible), ca prend pas enormement de place.

                                                                              Le probleme etant que des que tu passes sur un autre systeme, ca pete, parce que la taille du type de donnee a change.

                                                                              Un truc pareil, avec des dizaine d'autres langages cela n'arriverais pas.
                                                                              • [^] # Re: Bonne nouvelle

                                                                                Posté par  . Évalué à 1.

                                                                                La dernière perle dont tu nous as gratifié (à moins que… quelqu’un en voit une autre?) :
                                                                                « Le probleme etant que des que tu passes sur un autre systeme, ca pete, parce que la taille du type de donnee a change. »

                                                                                Ça pête juste pareil : 16 bits = 64 ko addressables, 32 bits = 4 Go addressables. malloc (INT_MAX) t’alloueras en fait toujours la moitié de la mémoire.
                                                                                • [^] # Re: Bonne nouvelle

                                                                                  Posté par  . Évalué à 1.

                                                                                  Tu crois ? Tu penses quoi du 8086 qui etait un processeur 16bit avec 20bit d'addressage ?
                                                                                  • [^] # Re: Bonne nouvelle

                                                                                    Posté par  . Évalué à 2.

                                                                                    Ou plus récent, le PAE (je m’attendais à ce que sortes celle-là), parce qu’à priori ça fonctionne sur le même principe : « The maximum linear address space was limited to 64 KB » Wikipedia.
                                                                                    • [^] # Re: Bonne nouvelle

                                                                                      Posté par  . Évalué à 1.

                                                                                      Moi je regardes la realite, sur les processeurs x86 16bits, allouer 64Ko ca se faisait tres regulierement et passait sans probleme car les machines avaient frequemment jusqu'a 16Mo de RAM (80286) et quasi toujours au moins 512Ko.

                                                                                      Allouer 2Go sur un processeur x86 32bits, dans 95% des cas l'allocation ne fonctionne pas car le systeme n'a pas 2Go dispo lineairement dans son espace d'addressage
                                                                                      • [^] # Re: Bonne nouvelle

                                                                                        Posté par  . Évalué à 2.

                                                                                        Ça c’est purement un problème de capacité des machines.

                                                                                        Alors effectivement un code qui alloue 2 Go n’est pas non plus portable sur une machine qui n’a que 1 Go. Ok, tu as gagné : le C n’est pas « portable ».

                                                                                        Sinon sur un vrai système (c’est du quick&dirty) :

                                                                                        #include <stdlib.h>
                                                                                        #include <stdio.h>

                                                                                        #define N 250000000
                                                                                        int main (int argc, char **argv) {
                                                                                          int *a;
                                                                                          int i;
                                                                                          a = (int*)malloc (N * sizeof (int));
                                                                                          printf ("%u\n", a);
                                                                                          for (i = 0; i < N; i++)
                                                                                            a[i] = 0;
                                                                                          printf ("zeros\n");
                                                                                          for (i = 0; i == 0;);
                                                                                          return 0;
                                                                                        }


                                                                                        J’alloue donc ~1 Go, j’ai 1 Go de RAM :
                                                                                        nicolas:~% ./a.out
                                                                                        2078031880
                                                                                        mon clavier s’est blo… nan je rigole ^^ par contre ça swappe
                                                                                        zeros

                                                                                        Résultat du TOP :
                                                                                        PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
                                                                                        23784 nicolas 20 0 955m 666m 172 R 100 66.6 0:19.75 a.out

                                                                                        Ça marche parce que mon système n’est pas en carton ^^, tant que j’alloue une quantité inférieure à la mémoire de RAM c’est bon…

                                                                                        D’ailleurs un spécialiste dans la salle pour me dire comment c’est possible ? Un malloc doit retourner une zone continue.
                                                                                        • [^] # Re: Bonne nouvelle

                                                                                          Posté par  . Évalué à 1.

                                                                                          Parce qu t'avais un Go d'espace d'addressage libre, et qu'il est alle tape dans la swap pour l'espace utilise qu'il a mappe dans ce 1Go d'espace d'addressage.

                                                                                          C'est pour ca que quand tu veux allouer 2Go sur un systeme 32bit tu commences a avoir de tres tres gros problemes, meme si t'as 4Go de RAM, parce Linux reserve automatiquement 1Go de l'espace d'addressage pour le kernel, ca laisse 3Go, sur lesquels il faut enlever ce qui est utilise par le systeme, et esperer avec ca avoir 2Go continus quelque part.

                                                                                          Resultat, t'as beau avoir 4Go de RAM, les chances d'arriver a allouer 2Go sont plutot faibles, alors qu'avec un 80x86 allouer 64Ko c'est chose facile. Resultat, quand tu passes ton code d'un systeme a l'autre, ca compile joliment et tout, tu lances et 3 minutes plus tard quand il fait l'alloc, boum !

                                                                                          C'est ce genre de choses qui font qu'en pratique, quand tu ecris du code un minimum complexe, tu te retrouves avec des problemes de portage en C.
                                                                                • [^] # Re: Bonne nouvelle

                                                                                  Posté par  . Évalué à 2.

                                                                                  Bon, bon, le probleme avec les exemples trop simples, c'est que c'est facile de pondre une excuse bidon pour que ca marche.

                                                                                  Prenons un probleme un tout petit peu plus realiste (mais tout de meme relativement simple):

                                                                                  Je veux lire un fichier dans une structure en memoire et ensuite acceder a une valeur val de taille t dans cette structure situee a offset du debut.

                                                                                  Le tout doit etre portable [*].

                                                                                  Tu trouves que le C c'est portable facilement, ca doit donc etre trivial pour toi a realiser en quelques minutes. Vas-y, prouves-nous que tu sais ce dont tu parles...

                                                                                  [*] c'est volontairement vague pour voir si t'y connais un minimum et que tu prevois plus que juste le cas general.
                                                                                  • [^] # Re: Bonne nouvelle

                                                                                    Posté par  . Évalué à 3.

                                                                                    « Le tout doit etre portable »

                                                                                    Par « le tout » je suppose que tu parles du code et du fichier de donnée. D’une remarque que j’ai précisé dès le début (pfiou ça remonte assez loin maintenant dans le fil) que je parle du code et pas des fichiers de données qui sortent.

                                                                                    Pour le code, comme je le dis et le répète : c’est portable, rien à faire. Pour du fichier de donnée portable et facile, pas de secret : format texte, printf&co à donf. c’est ce que je fais. Si tu veux du binaires : c’est casse-couille, faut manipuler la mémoire bit-à-bit pour forcer l’endianess&co, c’est portable, juste casse-couille, je n’ai personnellement jamais fait donc je ne saurais te pondre le code là comme ça en 10 minutes, mais c’est possible : c’est ce que fait très certainement la JVM, y’a pas de miracle !

                                                                                    « c'est volontairement vague » À tel point que je n’ai pas compris.
                                                                                    • [^] # Re: Bonne nouvelle

                                                                                      Posté par  . Évalué à 1.

                                                                                      Ouarf!
                                                                                      Change fichier de donnees par discussion reseau avec un autre client alors.
                                                                                      Fait la meme chose avec du Java, ou autre langage reellement multiplateforme, ton int envoye sera 32 bits dans une certaine endianness, quelque soit la machine faisant tourner le code.

                                                                                      C'est sur qu'avec comme une definition de portable telle que "ca compile", forcement, on va aller loin...
                                                                                      Bon, les deux compilations feront pas la meme chose, mais c'est pas grave ca, le code a compile donc il est portable.
                                                                                      Si tu vas par la un File file = new File("C:/Program Files"); c'est portable, ca compile!

                                                                                      If you can find a host for me that has a friendly parrot, I will be very very glad. If you can find someone who has a friendly parrot I can visit with, that will be nice too.

                                                                                    • [^] # Re: Bonne nouvelle

                                                                                      Posté par  . Évalué à 0.

                                                                                      Pour le code, comme je le dis et le répète : c’est portable, rien à faire. Pour du fichier de donnée portable et facile, pas de secret : format texte, printf&co à donf. c’est ce que je fais. Si tu veux du binaires : c’est casse-couille, faut manipuler la mémoire bit-à-bit pour forcer l’endianess&co, c’est portable, juste casse-couille, je n’ai personnellement jamais fait donc je ne saurais te pondre le code là comme ça en 10 minutes, mais c’est possible : c’est ce que fait très certainement la JVM, y’a pas de miracle !

                                                                                      C'est bien, tu commences a comprendre que c'est casse-couille la ou d'autres langages font cela de maniere transparente.
                                                                                      Tu commences a comprendre pourquoi on considere C comme pas trop portable en comparaison de ces langages.

                                                                                      Ensuite, tu te rendras compte que dans enormement de cas un format texte n'est pas realiste, et tu comprendras que dans enormement de cas C est casse-couille.
                                                                                    • [^] # Re: Bonne nouvelle

                                                                                      Posté par  . Évalué à 2.

                                                                                      Par « le tout » je suppose que tu parles du code et du fichier de donnée.

                                                                                      Le fichier de donnees est fixe (disons LE si tu veux). Le code doit etre capable de lire les donnees, quelque soit l'architecture et l'alignement. Comme plein de gens le disent depuis le debut sur le thread, c'est faisable, mais non trivial (et le langage ne te donne pas les briques pour le faire automatiquement, il faut tout gerer toi meme).

                                                                                      Pour le code, comme je le dis et le répète : c’est portable
                                                                                      je n’ai personnellement jamais fait donc je ne saurais te pondre le code là comme ça en 10 minutes, mais c’est possible

                                                                                      Ben le code il s'ecrit pas tout seul. Et apres tu viens dire aux autres de retourner sur les bancs de l’école. Faut etre gonfle quand meme!

                                                                                      Lorsque tu auras eu a ecrire du code portable qui manipule autre chose que des fichiers textes a coup de printf, tu pourras peut-etre la ramener...
                                                                                      • [^] # Re: Bonne nouvelle

                                                                                        Posté par  . Évalué à 1.

                                                                                        Déjà, j'ai du mal à attribuer de la crédibilité à quelqu'un qui utilise le terme « C/C++ ».

                                                                                        - temps de compilation interminable.
                                                                                        Et Java c'est rapide ? On a pas utilisé le même. Vu qu'on recompile en général que ce qui a été modifié (y compris pour Java je suppose), ce n'est pas très significatif sauf à être utilisateur de Gentoo.

                                                                                        - lib standard anoréxique.
                                                                                        - comportements non définis ( initialisation statique, accès concurrents...)
                                                                                        - compatibilité binaire très difficile à maintenir.

                                                                                        Mais il y a plein d'autres langages, pourquoi Java ?

                                                                                        IDE et outils peu puissants
                                                                                        Il est effectivement plus facile d'analyser un langage simpliste qu'un langage complexe.
                                                                                        Quant à Java, c'est bien le premier langage qui est à peu près inutilisable sans IDE monstrueux, je n'appelle pas ça un progrès.

                                                                                        DLFP >> PCInpact > Numerama >> LinuxFr.org

                                                                                        • [^] # Re: Bonne nouvelle

                                                                                          Posté par  . Évalué à 2.

                                                                                          Quant à des outils puissants, liés au langage, qui auraient contribué au succès de Java, je vois pas.

                                                                                          Justement il y en a plein, qui permettent de détecter quelques erreurs basiques par exemple. Ça ne t'évite pas de faire des architectures avec 40 Factory évidemment, bref c'est bien pour les boîtes qui emploient des développeurs incompétents et qui veulent limiter la casse. Bref, c'est le côté simpliste de Java qui permet ça, là où dans d'autres langages certaines fonctionnalités rendent l'analyse difficile.

                                                                                          DLFP >> PCInpact > Numerama >> LinuxFr.org

                                                                                          • [^] # Re: Bonne nouvelle

                                                                                            Posté par  . Évalué à 1.

                                                                                            A l'epoque des procs 16 bits, ca avait peobablement plein de sens, comme pb pg l'a explique. Maintenant, c'est sur que c'est moins pertinent.

                                                                                            Et ce code ecrit a l'epoque est potentiellement encore utilise de nos jours. Plus sous cette forme, certes, mais le jour ou le dev a recu son pentium flambant neuf, ca a du lui faire bizarre quand il a compile son appli.
                                                                                            Et mon petit doigt me dit qu'il a du mettre du temps a trouver la source du pb.

                                                                                            Je suis loin d'etre un expert en code natif, mais je serais pas surpris que d'autres problemes du meme tonneau sont apparus le jour ou des mecs ont passe leur appli en 64 bits.

                                                                                            If you can find a host for me that has a friendly parrot, I will be very very glad. If you can find someone who has a friendly parrot I can visit with, that will be nice too.

                                                                                            • [^] # Re: Bonne nouvelle

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

                                                                                              Oui, quand on code avec les pieds, le temps ne fait rien à l'affaire!

                                                                                              Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

                                                                                              • [^] # Re: Bonne nouvelle

                                                                                                Posté par  . Évalué à 0.

                                                                                                Aaaaah!
                                                                                                Ces ptis cons qui se croient meilleurs que tout le monde parce qu'ils ont implemente une liste chainee suite a leur 3ieme tp de C...

                                                                                                C'est sur que toi, t'as prevu toutes les evolutiosn de l'informatique pour les 30 prochaines annees.
                                                                                                Tu pourrais meme les inventer, la maintenant, mais tu preferes draguer la belette a la cafet' de la fac.

                                                                                                If you can find a host for me that has a friendly parrot, I will be very very glad. If you can find someone who has a friendly parrot I can visit with, that will be nice too.

                                                                                                • [^] # Re: Bonne nouvelle

                                                                                                  Posté par  . Évalué à 2.

                                                                                                  « C’est quoi la différence entre « imprévisible » (Java) et « ça dépend » (C++) ? La même qu’entre un bon et un mauvais chasseur ? »

                                                                                                  Quelque soit le langage, si celui-ci autorise des accès concurrents non-protégés, le résultat est nécessairement aléatoire. Ce n'est pas obligatoirement un « mauvais » résultat (certains algorithmes en tirent même parti), mais généralement ce n'est pas ce qu'on recherche.

                                                                                                  Ceci étant dit:

                                                                                                  Le modèle mémoire de Java (JMM) spécifie que si tu codes sans passer par des outils de synchro (locks, utilisation de volatile, etc), alors le comportement à l'exécution est indéfini. Si tu utilises les mécanismes de synchro, alors tu auras une exception à l'exécution (ou peut-être même une tape sur la main à la compil si tu as des outils intelligents).

                                                                                                  Dans le cas d'une utilisation correcte des méthodes de synchronisation, alors le JMM garantit une exécution suivant une politique appelée « sequential consistency » (SC). En gros, Du point de vue du thread qui s'exécute, l'ordre des instructions (au sens instruction load ou store dans la jvm) doit être celui spécifié dans le programme original, et toute écriture sur un des objets mémoire que le thread manipule (lecture ou écriture) doit lui apparaître selon l'ordre total de tous les threads qui s'exécutent en même temps.

                                                                                                  Je parle ici de programmes dits « data race free » i.e. qui ont des accès synchronisés aux variables partagées.

                                                                                                  Java a toujours eu un modèle mémoire concernant les accès concurrents, mais celui-ci est cassé/buggé. En 2004 une refonte du JMM a été commencée (et appliquée à partir de Java 1.5 si je me souviens bien).

                                                                                                  Le cas de C++ diffère, dans le sens où les threads ne faisaient pas partie du langage initialement. La prochaine norme va les intégrer au langage, ce qui signifie que C++ doit prendre position sur la façon dont les opérations en mémoire doivent être perçues par le programmeur et à l'exécution.

                                                                                                  C++MM suit plus ou moins le même modèle (SC pour les programmes sans accès concurrents aux données), avec quelques subtilités où ils précisent explicitement certains comportements indéfinis ou dépendants de l'implémentation (pour autoriser certaines optimisations impossibles dans le cas SC pur).
                                                                                                  • [^] # Re: Bonne nouvelle

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

                                                                                                    J'attends toujours qu'on me donne un exemple pertinent pour ce fameux malloc(INT_MAX). Je suis à peu près sûr qu'à part d'ex apprentis codeurs boutonneux, personne n'a jamais fait ça dans un programme sérieux.

                                                                                                    Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

                                                                                                    • [^] # Re: Bonne nouvelle

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

                                                                                                      J’avais oublié ce détail (une des nombreuses raisons que je fuis Java, pourtant…
                                                                                                      Eh sinon fait du C#, t'as des structures nommées Int16, Int32, Int64 ;)
                                                                                                      C'est d'ailleur assez rigolo de voir comment les approches divergent :
                                                                                                      en C#, int n'est qu'un alias de Int32, long un alias de Int64, short un alias de Int16.
                                                                                                      En C, c'est l'inverse, int32_t est un typedef de int ou autre en fonction de la plateforme.
                                                                                                      • [^] # Re: Bonne nouvelle

                                                                                                        Posté par  . Évalué à 2.

                                                                                                        pBpG t'as déjà répondu sur le fait que lorsque tu as effectivement peu de mémoire vive sur ta machine (donc à l'époque des 286,386 etc), avoir un tableau qui permettait d'indexer l'intégralité de la mémoire pour un coût relativement peu important (malloc(640*1024) par ex) ça avait son sens.

                                                                                                        malloc(INT_MAX) n'alloue pas toute la mémoire, juste un nombre maximal de cases qui peuvent stocker de l'information dans un tableau.
                                                                                                        • [^] # Re: Bonne nouvelle

                                                                                                          Posté par  . Évalué à 2.

                                                                                                          > A l'epoque des procs 16 bits, ca avait peobablement plein de sens, comme pb pg l'a explique.
                                                                                                          Bien au contraire, parce qu’à l’époque des processeurs 16 bits, beaucoup étaient également à adressage 16 bits, et donc malloc(INT_MAX) c’était allouer la moitié de l’espace d’adressage.
                                                                                                          • [^] # Re: Bonne nouvelle

                                                                                                            Posté par  . Évalué à 2.

                                                                                                            > C'est sur que toi, t'as prevu toutes les evolutiosn de l'informatique pour les 30 prochaines annees.
                                                                                                            Dans les faits, c’est le C qui a réussi à prouver qu’il pouvait tenir des décennies (presque 40 ans !) et toutes les évolutions qui se sont déroulées pendant ces décennies.
                                                                                                            Moi, je suis impatient de voir les développeurs Java dans 30 ans quand le programmeur lambda pourra se permettre des tableaux contenants des milliards d’éléments, avec la spec de leur langage où il est écrit en dur « l’index des tableaux, c’est 32 bits ».
                                                                                                            Si Java existe encore dans 30 ans, bien entendu.
                                                                                                            C’est sûr, le C aurait été plus « portable » (au sens assez restreint de mes contradicteurs où seule un langage garantissant à 100% la portabilité peut être qualifié de portable) si on avait mis en dur dans la spec « un entier, c’est 16 bits, un long 32, et un pointeur doit pouvoir tenir dans un long ». Pas sûr que le C aurait fêté ses 40 ans s’ils avaient fait ce choix (mais j’aurais été amusé de voir la tête de pBpG et des autres développeurs de Windows (Linux aussi du reste) si ce choix avait été fait. Comment ça on doit changer de langage de programmation et tout réécrire de A à Z pour faire du 64 bits ? Mais je croyais que le langage était plus portable quand on définissait explicitement tout !)
                                                                                                            • [^] # Re: Bonne nouvelle

                                                                                                              Posté par  . Évalué à 2.

                                                                                                              > avoir un tableau qui permettait d'indexer l'intégralité de la mémoire pour un coût relativement peu important
                                                                                                              Tu n’as _rien_ compris au message de pBpG.
                                                                                                              Quand tu indexes toute la mémoire, par définition, tu utilises toute la mémoire pour l’indexation (dit autrement : si tu essaies de faire une table de hashage dans laquelle la clef est l’adresse mémoire linéaire, alors rien que le stockage de tes clefs te prend la mémoire entière).
                                                                                                              Ce que pBpG dit, c’est que sur une machine où l’entier est à 16 bits mais où l’adressage est sur 20 bits — à l’aide de mécanismes comme la segmentation —, malloc(INT_MAX), c’est 16 fois moins (en fait 32, il a oublié que INT_MAX était signé) que l’espace adressable, donc que ça plantera pas — au contraire de nos machines où taille de l’entier = capacités d’adressage.
                                                                                                              C’est tout.
                                                                                                              Le seul exemple qu’il a donné, c’est « sur 16 bits on peut utiliser malloc(INT_MAX) pour allouer 64ko, et ça plante sur 32 bits », ce que j’appelle difficilement un exemple probant.
                                                                                                              • [^] # Re: Bonne nouvelle

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

                                                                                                                Mince mon programme plein de bidouilles spécifiques à ma machine d'il y a 20 ans ne fonctionne plus! Personne ne m'a dit que la taille des int pouvait changer!

                                                                                                                Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

                                                                                                                • [^] # Re: Bonne nouvelle

                                                                                                                  Posté par  . Évalué à 0.

                                                                                                                  Tu vois pas le rapport?
                                                                                                                  Dieu vivant du code?

                                                                                                                  T'etais ou ces 10 dernieres annees, quand google et facebook ont mene la scalabilite la ou elle n'a jamais ete?

                                                                                                                  Non, parce que tu viens de nous dire substance "le java c'est bon pour les boites qui embauchent des incompetents" je te demande donc d'annoncer a google qu'ils sont incompetents, ca devrait les faire rigoler vu le niveau de tes competences.

                                                                                                                  If you can find a host for me that has a friendly parrot, I will be very very glad. If you can find someone who has a friendly parrot I can visit with, that will be nice too.

                                                                                                                  • [^] # Re: Bonne nouvelle

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

                                                                                                                    Toujours indéfinis en Java, et dans tous les langages que je connais d’ailleurs.

                                                                                                                    Pardon je n'ai pas été clair : en Java, les opérations concurrentes suivent la norme qui dit dans quels cas elles donnent des résultats imprévisibles ou prévisibles.

                                                                                                                    En C++, la réponse est presque toujours "ça dépend".

                                                                                                                    La plupart des IDE « puissants » sont multi-langage. Quant à des outils puissants, liés au langage, qui auraient contribué au succès de Java, je vois pas.

                                                                                                                    Sauf que la complétion, les opérations de refactoring, de génération de code et de modélisation ne sont souvent bien implémentées que pour Java. C'est bien dommage d'ailleurs!

                                                                                                                    Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

                                                                                                                    • [^] # Re: Bonne nouvelle

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

                                                                                                                      Et Java c'est rapide ? On a pas utilisé le même. Vu qu'on recompile en général que ce qui a été modifié (y compris pour Java je suppose), ce n'est pas très significatif sauf à être utilisateur de Gentoo.

                                                                                                                      Essaye avec de gros projets, tu verras la différence.

                                                                                                                      Mais il y a plein d'autres langages, pourquoi Java ?

                                                                                                                      Il était là au bon moment, avec la bonne com?

                                                                                                                      Quant à Java, c'est bien le premier langage qui est à peu près inutilisable sans IDE monstrueux, je n'appelle pas ça un progrès.

                                                                                                                      Oui, mais les gens aiment les gros IDE. Tu peux toujours essayer de les convaincre qu'avec ton VIM et ton GDB, on peut être plus productif, ça ne marchera pas.

                                                                                                                      Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

                                                                                                                      • [^] # Re: Bonne nouvelle

                                                                                                                        Posté par  . Évalué à 3.

                                                                                                                        Le Java c'est bon pour les boîtes qui embauchent des incompétents, ça veut pas dire que tous les gens qui font du Java sont des incompétents. Comme d'habitude les principes logiques de base t'échappent et tu te rabats sur des attaques ad hominem. « Vu le niveau de tes compétences » ? Tu as pas mieux ?

                                                                                                                        Quant à Facebook, oui c'est clairement une boîte d'incompétents mais ils font surtout… du PHP.

                                                                                                                        DLFP >> PCInpact > Numerama >> LinuxFr.org

                                                                                                                        • [^] # Re: Bonne nouvelle

                                                                                                                          Posté par  . Évalué à 3.

                                                                                                                          > Je comprends que ca caresse ton ego de tout faire a la main, mais le but du jeu c'est de produire des applis, pas de se mesurer la quequette a base de ki k'est le plus hardcore.
                                                                                                                          Allez, encore un petit effort et tu pourras être encore plus insultant.

                                                                                                                          Bon, comme tu as l’air d’être un peu dur à la compréhension, je répète. Tu me dis :
                                                                                                                          - Java a de bons IDE => Java est un bon langage (plus exactement, tu as dit : la qualité de ses IDE est une mesure de la qualité d’un langage)
                                                                                                                          Je te dis: c’est faux, parce que la bonne relation de causalité est:
                                                                                                                          - Java nécessite un IDE pour être utilisé => Java a de bons IDE
                                                                                                                          Avec, pour argument : de très bons langages, qui ne nécessitent pas d’IDE, ne donnent pas une telle « culture de l’IDE » : Ruby et Python par exemple. L’immense majorité des devs de RoR sont soit sous vim, soit sous TextMate. Ce se sont incompétents ? Des narcissiques qui préfèrent « se mesurer la quequette » plutôt que d’être productifs ?
                                                                                                                          C++, qui, au niveau « nécessité de l’utilisation d’un IDE », se situe entre Python et Java, ben se situe également entre les deux sur « qualité des IDE » (refactoring moins bon voire inexistant par exemple) et sur « nombre de programmeurs préférant travailler avec un IDE en C++ »

                                                                                                                          > mais le but du jeu c'est de produire des applis
                                                                                                                          Putain, j’aurais jamais deviné tout seul. Merci beaucoup de m’avoir prévenu, heureusement que tu es là.
                                                                                                                          Maintenant, est-ce qu’il ne te serait pas venu à l’esprit que :
                                                                                                                          - l’utilisation des IDEs a des avantages mais aussi des inconvénients (naoon, pas possible !)
                                                                                                                          - le poids de ces avantages et de ces inconvénients diffère selon le langage et même la personne (fou hein !)
                                                                                                                          - et que donc, au niveau productivité, l’utilisation ou non d’un IDE dépend du langage, du projet, et de la personne (bon, je commence à avoir mal à l’épaule à force d’enfoncer des portes ouvertes)
                                                                                      • [^] # Re: Bonne nouvelle

                                                                                        Posté par  . Évalué à 2.

                                                                                        T’es mignon, mais perso. je code pas ce genre de truc, j’utilise ASCII (pour toi c’est peut-être une marque d’incompétence, pour moi… c’est juste aller au plus vite avec la solution du moment, et c’est parfaitement portable), quand c’est pas trop lourd j’utilise des libs qui font le boulot derrière, faite par des gens qui y ont passé du temps dessus. Je manipule régulièrement plusieurs Go de données numériques, j’ai eu à lire une fois du binaire écrit par du Fortran, c’est clairement la gageure et c’est un gros boulot en soit (faut y aller octet par octet presque, mais faute au Fortran qui est horrible à ce niveau). Tu parles que j’ai vite fait de le convertir dans un format binaire portable et facile à manipuler. Mes connaissances actuelles ne sont clairement pas suffisantes pour taper dans du binaire multi-plateforme, là comme ça, et surtout pas pour un troll, c’est un boulot en soit, mais comme presque tout en C, tu me donnes un mois je te sors un format de fichier binaire au poil, et totalement portable. Mais ce n’est pas possible de discuter avec vous, vous remettez en doute sans cesse mes compétences, mais n’hésite pas toi à me donner ton pedigree.

                                                                                        « Comme plein de gens le disent depuis le debut sur le thread, c'est faisable, mais non trivial »

                                                                                        Et ben je crois qu’on est « tombé » d’accord. Enfin… mis à part qu’on a dévié, dès mon second commentaire j’ai bien fait la distinction entre le code et les fichiers de données. Il faut faire la distinction. Le code est portable, les fichiers binaires ne l’ont jamais été.

                                                                                        Ce sera mon dernier commentaire.
                                                                                        • [^] # Re: Bonne nouvelle

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

                                                                                          Le code est portable, les fichiers binaires ne l’ont jamais été
                                                                                          Ce sera mon dernier commentaire.

                                                                                          C'est con c'est exactement l'inverse :) Le problème n'est pas le fichier binaire en soit : lui est parfaitement portable et à peu prêt tous les systèmes sont capables de stocker un fichier en conservant sa structure intacte.
                                                                                          Par contre, le code qui lit/écrit le fichier, s'il est écrit en C, a un comportement différent suivant la machine sur laquel il s'exécute : il va intepréter différemment le fichier suivant l'architecture.
                                                                                          • [^] # Re: Bonne nouvelle

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

                                                                                            Eh tu vas rire, mais en Java, y'a un type "long" et un type "double".
                                                                                            Tu vas rire, mais tu les utilises indépendament de ton architecture : que ce soit du 16, 32, 64 bits, ou pourquoi pas demain 128 ou je ne sais quoi.
                                                                                            Et là tu vas te bidonner : même que Java, si le besoin s'en fait ressentir, peut évoluer, tout comme le C évolue...

                                                                                            Comment ça on doit changer de langage de programmation et tout réécrire de A à Z pour faire du 64 bits ?
                                                                                            C'est quoi cet argument ridicule ? Le C s'est vu ajouté des types à taille fixe en 99, et personne ne trouve que c'est un boulet, bien au contraire. Si demain il y a besoin de types plus large encore, il suffira de rajouter de nouveaux keywords, waouuh va falloir tout réécrire ?

                                                                                            Non clairement en C il faut utiliser ces types à taille fixe si on veut du code portable, et il n'y a aucun inconvénient lié à l'évolutivité des plateformes.
                                                                                        • [^] # Re: Bonne nouvelle

                                                                                          Posté par  . Évalué à 2.

                                                                                          Mais ce n’est pas possible de discuter avec vous, vous remettez en doute sans cesse mes compétences, mais n’hésite pas toi à me donner ton pedigree.

                                                                                          Calme toi et laisse tomber. Il n'y aura plus de discussion si tant est qu'il en est eu une. C'est un des tactiques preferes des personnes paye par microsoft pour pourrir leurs opposants.
                                                                                          • [^] # Commentaire supprimé

                                                                                            Posté par  . Évalué à 0.

                                                                                            Ce commentaire a été supprimé par l’équipe de modération.

                                                                                            • [^] # Re: Bonne nouvelle

                                                                                              Posté par  . Évalué à 1.

                                                                                              Alors, deja, les devs java sont assez rare a utiliser les tableaux, ils passent par des Collection, qui sont beaucoup plus flexible, permettent du lazy loading (preferable si tu charge effectivement 2^45-1, meme si t'as un pc quantique a 128Go de cache L1). La derniere fois que je l'ai fait, c'etait sur une lib crypto, j'ai hate de voir le jour ou les cles de 2^63 -1 bits vont arriver, ou celui ou on sera capable de chiffrer des msg de 2^63-1 bits.

                                                                                              D'autre part, les devs java updateront leur code bien tranquillement, pendant que les devs C seront en train d'en chier a updater leur implem de tout ce qui touche au binaire, parce que les int sont passe de 32 a 64b un beau matin, que ca fout la grouille partout et qu'en plus on s'en rend pas forcement compte sauf dans des cas speciaux.

                                                                                              If you can find a host for me that has a friendly parrot, I will be very very glad. If you can find someone who has a friendly parrot I can visit with, that will be nice too.

                                                                                            • [^] # Commentaire supprimé

                                                                                              Posté par  . Évalué à 3.

                                                                                              Ce commentaire a été supprimé par l’équipe de modération.

                                                                                              • [^] # Re: Bonne nouvelle

                                                                                                Posté par  . Évalué à 3.

                                                                                                < mode troll > Dans les faits c'est le fortran qui a reussi a prouver qu'il pouvait tenir des decennies (plus de 50 ans) < / >
                                                                                                • [^] # Re: Bonne nouvelle

                                                                                                  Posté par  . Évalué à 3.

                                                                                                  pourtant ma boite sert 20 millions de visiteurs uniques par mois

                                                                                                  C'est pas toi qui raille sur la mesure de taille de quéquette dans un autre commentaire ?

                                                                                                  Je ne vois pas le rapport entre le nombre de visiteurs et la compétence. Et c'est quoi cette mode de balancer des noms de grosses boîtes comme si c'était des dieux vivants du code ?

                                                                                                  DLFP >> PCInpact > Numerama >> LinuxFr.org

                                                                                                  • [^] # Re: Bonne nouvelle

                                                                                                    Posté par  . Évalué à 0.

                                                                                                    Ce que pBpG dit, c’est que sur une machine où l’entier est à 16 bits mais où l’adressage est sur 20 bits — à l’aide de mécanismes comme la segmentation —, malloc(INT_MAX), c’est 16 fois moins (en fait 32, il a oublié que INT_MAX était signé) que l’espace adressable, donc que ça plantera pas — au contraire de nos machines où taille de l’entier = capacités d’adressage.
                                                                                                    C’est tout.
                                                                                                    Le seul exemple qu’il a donné, c’est « sur 16 bits on peut utiliser malloc(INT_MAX) pour allouer 64ko, et ça plante sur 32 bits », ce que j’appelle difficilement un exemple probant.


                                                                                                    Vraiment ? Pourtant c'est un exemple reel, qui demontre que non, C n'est pas un langage multi-plateforme du fait de la non definition de ses types de base parmis d'autres faiblesses au niveau support multiplateformes.

                                                                                                    Tu iras des lors expliquer a ce code qu'il n'a jamais existe, et qu'il n'avait pas non plus lieu d'exister.
                                                                                                    • [^] # Re: Bonne nouvelle

                                                                                                      Posté par  . Évalué à 1.

                                                                                                      C'est bien, tu viens de nous dire nois sur blanc que tu avais du code specifique a la machine en C, qui donc n'etait pas portable.

                                                                                                      Merci de confirmer ce que je dis depuis le debut.

                                                                                                      La prochaine fois, reflechis avant d'ecrire.
                                                                                                      • [^] # Re: Bonne nouvelle

                                                                                                        Posté par  . Évalué à 4.

                                                                                                        simple != simpliste

                                                                                                        C'est un peu comme le Lisp, la grammaire de base est extrêmement simple, pourtant c'est un langage très puissant.
                                                                                                        Bah KISS c'est pareil, c'est simple et efficace sans être simpliste.
                                                                                        • [^] # Re: Bonne nouvelle

                                                                                          Posté par  . Évalué à 1.

                                                                                          Mais ce n’est pas possible de discuter avec vous, vous remettez en doute sans cesse mes compétences, mais n’hésite pas toi à me donner ton pedigree.

                                                                                          Personnellement, c'est pas que je remettes en cause tes competences, je te connais pas, mais ca fait plus de 15 ans que je fais du C, avec pas mal de multiplateforme justement (j'ai d'ailleurs fait que ca jusqu'a mon arrivee chez MS: un soft tournant sur MIPS, PPC, x86, Sparc avec NetBSD, Linux, IRIX, Windows & Solaris comme OS), alors quand j'entends dire que C c'est un langage multiplateforme, ca herisse les poils, et quand tu me montres plus haut que tu ne comprends pas pourquoi tu peux allouer 1Go sur un systeme avec 1Go de RAM physique, ca me conforte dans l'idee que tu ne maitrise pas forcement tout ce dont tu parles.
                                                                                          • [^] # Re: Bonne nouvelle

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

                                                                                            de très bons langages, qui ne nécessitent pas d’IDE, ne donnent pas une telle « culture de l’IDE »

                                                                                            Est-ce que ce n'est pas plutôt la culture du "mon langage n'a pas la feature X, du coup je clame qu'il est tellement bien qu'on n'en a pas besoin"?

                                                                                            Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

                                                                                            • [^] # Re: Bonne nouvelle

                                                                                              Posté par  . Évalué à 2.

                                                                                              Je me fatigue à me répéter…

                                                                                              > Pourtant c'est un exemple reel,
                                                                                              Comme ce qu’on trouve sur http://thedailywtf.com/

                                                                                              Encore une fois, c’est quoi la sémantique derrière malloc(INT_MAX) dans un exemple de code correct ? Si c’est "allouer 64K", permets-moi de crier bullshit : c’est un code qui aurait sa place sur DailyWTF, tout comme new int[(int)math.PI] le serait pour créer un tableau de 3 entiers.
                                                                                              Et si c’est pour dire que C est moins neuneu-proof, encore une fois (ça fera combien de fois dans ce fil ?) : je sais.
                                                                                              • [^] # Re: Bonne nouvelle

                                                                                                Posté par  . Évalué à 3.

                                                                                                Tu veux dire que je peux pas faire de code spécifique au système dans Java, que c’est totalement impossible ?
                                                                                                Je suppose donc que je ne peux pas savoir :
                                                                                                - sur quel OS je tourne, et agir en conséquence
                                                                                                - l’endianness de la machine hôte, et agir en conséquence (par exemple IPC avec un programme écrit en C++ qui partage ses données dans le sens de la machine hôte)
                                                                                                - la JVM sur laquelle je tourne, et agir en conséquence
                                                                                                • [^] # Re: Bonne nouvelle

                                                                                                  Posté par  . Évalué à 1.

                                                                                                  C’est quoi la différence entre « imprévisible » (Java) et « ça dépend » (C++) ? La même qu’entre un bon et un mauvais chasseur ?

                                                                                                  > Sauf que la complétion, les opérations de refactoring, de génération de code et de modélisation ne sont souvent bien implémentées que pour Java. C'est bien dommage d'ailleurs!
                                                                                                  Refactoring, peut-être (jamais essayé les outils de refactoring d’eclipse dont on me rebat tant les oreilles), pour le reste, tu as totalement craqué, n’importe quel IDE un tant soit peu complet est capable de faire ça pour le C ou le C++
                                                                                                  • [^] # Re: Bonne nouvelle

                                                                                                    Posté par  . Évalué à 1.

                                                                                                    > Oui, mais les gens aiment les gros IDE.
                                                                                                    Ça, ça dépend complètement du langage. Effectivement, l’immense majorité des devs Java aiment les gros IDE, mais c’est exactement parce que le langage est inutilisable sans (forcément, étant donné que les 3/4 du code sont tellement trivial qu’un IDE peut le générer et qu’un être humain se fait chier à en crever à l’écrire…)
                                                                                                    Les développeurs Python, Ruby et PHP n’aiment en général pas les IDE parce que ces derniers sont incapables d’utiliser toute la puissance de leur langage (et pourtant, la puissance de PHP…)
                                                                                                    Pour les développeurs C et C++, ça dépend franchement des milieux.
                                                                                          • [^] # Re: Bonne nouvelle

                                                                                            Posté par  . Évalué à 2.

                                                                                            Je déroge à ma règle concernant ma question uniquement, car si quelqu’un a une réponse, elle m’intéresse fortement.

                                                                                            J’ai un système de 1 Go de RAM, et 1 Go de SWAP. Environ 250 Mo de la RAM et 180 Mo du SWAP sont occupés. Je fais un malloc de environ 1 Go, il doit me trouver une mémoire continue. Il ne peut physiquement exister 1 Go de mémoire continue, pourtant, le système me la donne lors du malloc. Ma question est : comment le kernel gère ça ?
                                                                                            • [^] # Re: Bonne nouvelle

                                                                                              Posté par  . Évalué à 4.

                                                                                              • [^] # Re: Bonne nouvelle

                                                                                                Posté par  . Évalué à 2.

                                                                                                Écoute, si c’est pour ne pas me lire et répondre en automatique à partir de quelques mots clefs, c’est pas la peine de me répondre. Tu n’y es pas légalement obligé.

                                                                                                > Eh tu vas rire, mais en Java, y'a un type "long" et un type "double".
                                                                                                Aucun, mais alors vraiment aucun rapport avec ce que j’ai écrit.
                                                                                                Ou alors on peut utiliser les double pour indexer des tableaux en Java. Dans ce cas, c’est une killer feature que vous devriez mettre en avant.

                                                                                                > Et là tu vas te bidonner : même que Java, si le besoin s'en fait ressentir, peut évoluer,
                                                                                                Ben nan, et c’est très précisément ce que je voulais dire.
                                                                                                En C, on a pas défini en dur « taille d’un pointeur », de même qu’on a pas défini en dur « type de l’indice d’un tableau » dans la spec. Alors ça pose quelques soucis de portabilité à certains gruiks qui voyant que sur leur machine sizeof(int) = sizeof(void*) pensent qu’ils peuvent caster des int en void* et vice-versa, certes, mais ça laisse le champ libre à l’évolution du C.
                                                                                                Donc quand on est passé de 16 bits à 32 bits puis 32 bits à 64 bits, pas de souci pour passer de tableaux contenant des dizaines de milliers d’éléments à des millions, et on aura ensuite aucun souci pour passer de tableaux contenant des centaines de millions d’éléments à des tableaux de plusieurs milliards d’éléments.
                                                                                                Au contraire, Java a dit :
                                                                                                - int = 32 bits
                                                                                                - indice des tableaux = int. long doit balancer une exception [http://java.sun.com/docs/books/jls/second_edition/html/array(...)]
                                                                                                Ergo, avec Java, tu ne pourras tout simplement pas faire de tableaux de quelques milliards d’éléments même quand ce sera monnaie « courante » chez d’autres langages.

                                                                                                Le but est juste de montrer les inconvénients de définir une taille d’entiers fixes, pourquoi le C a choisi de ne pas le faire, et pourquoi ce choix a été un facteur de réussite sur le long terme.

                                                                                                Tu veux un autre exemple ? Prenons le cas où j’ai codé un algorithme sur ma machine 32 bits, que je veux utiliser sur un processeur 16 bits sans addl (je pense qu’on peut plus en trouver aujourd’hui, mais ça a existé).
                                                                                                En Java :
                                                                                                - soit la JVM n’existe pas pour cette machine : on a rien pour faire de l’int
                                                                                                - soit la JVM force artificiellement le 32 bits à l’aide d’une fonction addl, et bonjour les performances où toute opération sur un int c’est un appel de fonction
                                                                                                - donc, en pratique, je fais un sed s/int/short/g MonAlgo.java > MonAlgo-16.java
                                                                                                En C:
                                                                                                - je recompile et ça juste marche (tm). Sauf si bien sûr j’ai codé comme un porc.
                                                                                                - différence entre les plateformes : les limites de mon algorithme sont plus basses sur la machine 16 bits. Rien qui ne me choque là-dedans.
                                                                                                Pour moi, sur cet exemple, le C est plus portable.

                                                                                                Encore une fois, ce que je dis, c’est ça :
                                                                                                - le fait de ne pas fixer les tailles en C a été un choix
                                                                                                - ce choix, en pratique, revient à privilégier une forme de portabilité (algorithme qui s’adapte « automagiquement » aux capacités de la machine) sur une autre (certaines opérations peuvent « tomber en marche » sur une machine et planter 2 ans plus tard quand tu changes de machine)
                                                                                                - ce choix a été un des facteurs de succès du C sur le long terme

                                                                                                > Non clairement en C il faut utiliser ces types à taille fixe si on veut du code portable
                                                                                                Que dalle. Il faut utiliser des entiers de taille et d’endianness fixe pour la communication avec l’extérieur et vérifier les tailles lors de la sérialisation/déserialisation, c’est tout.
                                                                                                Si je veux un "entier sur 32 bits", parce que ça a un sens sémantiquement dans le contexte (pour coder une couleur RGBA par exemple), oui, je prend un entier de taille fixe.
                                                                                                Si je veux juste "un nombre sur lequel ma machine peut faire des opérations arithmétiques" (l’immense majorité des algos), je prend un int.
                                                                                                Bon sang, c’est juste une règle de bonne conduite dans tout projet et dans tout langage : un choix d’ordre sémantique doit être explicité ! int et int32_t, ce n’est pas _du tout_ la même chose sémantiquement, et si tu les mélanges au petit bonheur la chance, c’est pas la faute du langage, c’est parce que tu ne sais pas ce que tu fais, et dans ce cas, comme le disait mon prof d’ingénierie logicielle : tu enlèves les mains de ton clavier et tu réfléchis. unsigned int rgbaColor = 0xdeadbeef, c’est une hérésie, que ce soit en C ou en Java, parce que pour du RGBA-32, la taille a un sens important. Même si ça marche et c’est portable en Java, c’est du même ordre que mon exemple new int[(int)PI] : c’est pas parce que _par hasard_ la constante ((int)PI ou sizeof(int)) marche pour mon problème qu’il est correct de l’utiliser !

                                                                                                > C'est quoi cet argument ridicule ?
                                                                                                Relis mon exemple. Tu ne l’as pas compris.

                                                                                                tl;dr : sur la question de la taille des entiers, il n’y a pas un langage plus ou mois portable qu’un autre entre Java et C : il y a portabilité formelle (si ma fonction multiplyByTwo fonctionne sur une architecture avec 2**30 en entrée, alors elle doit fonctionner partout avec cette entrée, même si ça signifie que toute opération sur un int doit être ralentie (à la louche) d’un facteur 10 ou plus si la machine ne sait pas faire nativement) pour Java contre portabilité sémantique (la sémantique générale de l’algorithme multiplyByTwo est préservée, mais ses limites dépendent de la machine) pour le C
                                                                                                • [^] # Re: Bonne nouvelle

                                                                                                  Posté par  . Évalué à 0.

                                                                                                  mais ils font surtout… du PHP.
                                                                                                  Mouhahaha!
                                                                                                  T'en as pas marre de te ridiculiser serieux?

                                                                                                  If you can find a host for me that has a friendly parrot, I will be very very glad. If you can find someone who has a friendly parrot I can visit with, that will be nice too.

                                                                                                  • [^] # Re: Bonne nouvelle

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

                                                                                                    Pourtant c'est un exemple reel

                                                                                                    D'où as-tu sorti cette exemple débile? On attends toujours que tu nous sortes un cas concret et pas un vague "ça pouvait être utile il y a 20 ans je crois peut être".

                                                                                                    Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

                                                                                                    • [^] # Re: Bonne nouvelle

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

                                                                                                      C'est bien, tu viens de nous dire nois sur blanc que tu avais du code specifique a la machine en C, qui donc n'etait pas portable.

                                                                                                      C'est TON code qui est tout moisi :-)

                                                                                                      Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

                                                                                                • [^] # Re: Bonne nouvelle

                                                                                                  Posté par  . Évalué à 2.

                                                                                                  Au fait, pour ceux qui se poseraient la question devant ce ramassis de connerie, allouer 2 Go sur une machine de 32 bits est parfaitement faisable, il faut juste avoir la mémoire nécessaire, et, remercions PAE et *-bigmem, il devrait être possible d’allouer 4 Go sur une machine qui contient suffisament de RAM.
                                                                                            • [^] # Re: Bonne nouvelle

                                                                                              Posté par  . Évalué à 1.

                                                                                              Je te l'ai donnee plus haut la reponse, c'est cette meme reponse qui t'explique pourquoi un malloc(INT_MAX) est tout a fait acceptable sur un CPU tel que le 80286 et que le _meme_ code explose sur un x86 32bit
                                                                                              • [^] # Re: Bonne nouvelle

                                                                                                Posté par  . Évalué à 1.

                                                                                                Ton soft gere des elements(peu importe quoi), et tu utilises un ID pour les differencier, qui est un int.

                                                                                                Combien d'elements maximum peut-il gerer ? MAX_INT ...

                                                                                                Quel est le moyen le plus rapide d'acceder a ces elements ? Une table contenant ces elements, une table de taille ... MAX_INT

                                                                                                --> malloc(MAX_INT) ou MAX_INT*(ce que tu veux)

                                                                                                C'est peut-etre pas optimal, mais c'est pas stupide non plus hein quand la taille au final est bien plus petite que la RAM dispo sur les machines standards.

                                                                                                Ca a tout son sens quand ton soft gere 32768 (ou 65536 avec MAX_UINT) elements, le probleme etant quand tu 4 ans plus tard un nouveau systeme sort, et il a des int sur 32bits, et boum, tu te retrouves avec ta table qui fait 2 milliards d'entrees.

                                                                                                Et devines quoi, aujourd'hui tout le monde a un systeme avec CPU 64bits, et des int 32bits, d'ici quelque annees tout le monde aura 128Go de RAM en standard sur son iPad/desktop/frigo et on verra regulierement des tables de 2^32 elements, tu sais, MAX_UINT, ou si ce n'est l'allocation elle-meme, une reservation d'espace d'addressage continu de cette taille a remplir au fur et a mesure des besoins(ca se fait probablement deja aujourd'hui dans des bases de donnees).

                                                                                                Et dans quelque annees, un nouvel OS(ou ancien et modernise) bien joli va sortir tout 64bit et tout, avec des int de 64bit vu que tout le monde a 128Go de RAM et qu'un int 32bit c'est devenu ringard, et boum, la meme merde.

                                                                                                Quand t'as des types de taille statique, ce genre de merde n'arrive pas, si tu passes ton soft sur le nouvel OS, ton code il marche, point.
                                                                                              • [^] # Re: Bonne nouvelle

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

                                                                                                Java et .C# sai nul, on peut même pas faire un :

                                                                                                byte[] gros = new byte[java.Integer.MAX_INT];

                                                                                                C'est pas portable! Sur les machines avec moins de 4Go de RAM ça ne marche pas!!! Bouh!

                                                                                                Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

                                                                                                • [^] # Re: Bonne nouvelle

                                                                                                  Posté par  . Évalué à 3.

                                                                                                  Comme tu dis toi-même, dans ce cas, le fait que ça marche ou pas ne dépend pas de l’architecture de la machine mais des capacités de la machine.
                                                                                                  Ce qui n’est pas en soit surprenant.

                                                                                                  > Ca a tout son sens quand ton soft gere 32768
                                                                                                  Tu mélanges deux situations différentes. Ton soft gère 32768 éléments ou MAX_INT éléments ? Ce n’est pas la même chose.
                                                                                                  Cas où ton soft gère 32768 éléments : ben tu fais pas MAX_INT, mais #define MAXELEMS
                                                                                                  Cas où ton soft gère MAX_INT : tu aimerais bien que ton algo scale avec les capacités de ta machine, donc il me semble normal que MAX_INT change selon l’architecture, et tant pis si ça plante pour une machine pas assez puissante.

                                                                                                  > et on verra regulierement des tables de 2^32 elements
                                                                                                  Ha, mais c’est exactement mon argument plus bas, hein !
                                                                                                  1. Là où Java est portable dans le sens où il garantit que l’algo aura les mêmes limites partout, là où C est portable dans le sens où l’algo « scale » avec les capacités de la machine.
                                                                                                  2. Justement, je suis impatient de voir comment fera Java quand on verra régulièrement des tables de 2^32 éléments, alors qu’il est écrit dans sa spec que l’index d’un tableau, c’est 32 bits.

                                                                                                  > Quand t'as des types de taille statique, ce genre de merde n'arrive pas, si tu passes ton soft sur le nouvel OS, ton code il marche, point.
                                                                                                  Mais il est incapable de profiter de la puissance de ce nouvel OS flambant neuf, et au final, si tu veux en profiter, tu es obligé de recoder ton programme en changeant des int par des long.
                                                                                                  C’est pas « plus » ou « moins » portable, c’est différent. Pour une FFT fenêtrée de taille fixe sur un stream, l’approche Java est plus adaptée. Pour de la manipulation d’images, l’approche C est plus adaptée (tu aimerais que la limite en taille d’image puisse s’adapter avec l’évolution du matos : images 170 par 170 au max sur du 16 bits, 65000 par 65000).
                                                                                                  • [^] # Re: Bonne nouvelle

                                                                                                    Posté par  . Évalué à 0.

                                                                                                    Non, facebook n'est pas "ecrit en PHP".
                                                                                                    Je sais pas, c'est un peu comme si tu disais que internet est ecrit en C parce que les serveurs web sont generalement du apache.

                                                                                                    Ca veut rien dire en premier lieu, vu le nombre de composants implique dans un site pareil, le php n'est que la partie visible de l'iceberg.
                                                                                                    Mon petit doigt me dit qu'ils ont qq palettes de Java pour les applis, avec du c/c++ pour les composants qui necessite une optimisation "native", pas mal de python et/ou de ruby pour tout ce qui est script interne et probablement d'autres trucs auquels j'ai pas pense..
                                                                                                    Par dessus tout ca, tu rajoutes des camions entiers de mysql avec probablement pas mal de procedures stockees, qq containers de hadoop + hives pour tout ce qui est traitement des donnees.
                                                                                                    Et au dessus tout ca, pour la partie que toi tu vois, ils ont des pages php (qu'ils compilent en c++ au final...).

                                                                                                    A ton avis, le data mining dans le demi milliards d'utilisateurs, il tourne en php?
                                                                                                    Tout le backend, il tourne en php?

                                                                                                    La partie en php, c'est la partie "facile" (bon, facile, tout est relatif vu la charge, mais c'est pas le plus complique clairement), c'est juste du rendu html. Traiter les millions de photos qu'ils font par jour, mettre a jour les walls en temps reel, construire les graphes d'utilisateurs gigantesque et tout ce genre de connerie, tu crois *vraiment* que c'est fait en php?

                                                                                                    Et google search, tu vas me dire qu'il font surtout du python?

                                                                                                    Pourquoi tu ne réponds pas au reste, plutôt que dire que je suis « ridiculisé » ?
                                                                                                    Parce que tu me fais rire quand tu te sent coince, tu sort ton parapluie geant et tu commence a nier ce que t'as dit 2 messages plus haut.

                                                                                                    If you can find a host for me that has a friendly parrot, I will be very very glad. If you can find someone who has a friendly parrot I can visit with, that will be nice too.

                                                                                                    • [^] # Re: Bonne nouvelle

                                                                                                      Posté par  . Évalué à 2.

                                                                                                      Là encore, tu ne comprends rien à la logique. Il y a du PHP dans Facebook, partout, vu qu'il a commencé à être développé avec. Ce n'est pas parce que d'autres choses sont utilisées que « Facebook est écrit en PHP » est faux. Tu veux dire le contraire de tout ce qui est dit sur DLFP, c'est maladif et ridicule, ton délire sorti de nulle part sur ce que Facebook utilise peut-être en est un parfait exemple.

                                                                                                      Parce que tu me fais rire quand tu te sent coince, tu sort ton parapluie geant et tu commence a nier ce que t'as dit 2 messages plus haut.
                                                                                                      Ta tactique d'argumentation principale est de déformer les propos des autres et plus personne ici n'est dupe. Tu peux dire où je me suis contredit ?

                                                                                                      DLFP >> PCInpact > Numerama >> LinuxFr.org

                                                                                                • [^] # Re: Bonne nouvelle

                                                                                                  Posté par  . Évalué à 1.

                                                                                                  T'as un truc intelligent a dire au passage ?

                                                                                                  Parce qu'un malloc(INT_MAX) sur certains systemes a tout son sens, et sur d'autres absolument aucun, alors qu'un byte[] gros = new byte[java.Integer.MAX_INT] lui a _toujours le meme sens_ ou que ce soit. Et c'est bien ca qui fout la merde avec le C, le meme code se comporte differement d'un systeme a l'autre.

                                                                                                  Mais bon, c'est tellement plus simple de sortir des inepties plutot que regarder la verite en face ...
                                                                                                  • [^] # Re: Bonne nouvelle

                                                                                                    Posté par  . Évalué à 1.

                                                                                                    Tu mélanges deux situations différentes. Ton soft gère 32768 éléments ou MAX_INT éléments ? Ce n’est pas la même chose.
                                                                                                    Cas où ton soft gère 32768 éléments : ben tu fais pas MAX_INT, mais #define MAXELEMS
                                                                                                    Cas où ton soft gère MAX_INT : tu aimerais bien que ton algo scale avec les capacités de ta machine, donc il me semble normal que MAX_INT change selon l’architecture, et tant pis si ça plante pour une machine pas assez puissante.


                                                                                                    Sans blague ? Merci je connais, mais moi je regardes pas la theorie de ce que t'es sense faire et que 1% des gens font, mais ce que l'enorme majorite des gens font, parce qu'au final si le langage est tellement alambique que personne ne sait, c'est comme si le langage ne le faisait pas.

                                                                                                    La realite est que l'enorme majorite des developpeurs ne sait meme pas qu'un int peut avoir une taille differente d'un systeme a l'autre. Cette realite fait que tous ces softs qu'ils ont ecrits ne sont probablement pas multiplateforme.

                                                                                                    La realite est qu'un soft ecrit par un neuneu en Java/Python/autre lui par contre il a toutes les chances de tourner sur plein de plateformes differentes.

                                                                                                    Mais il est incapable de profiter de la puissance de ce nouvel OS flambant neuf, et au final, si tu veux en profiter, tu es obligé de recoder ton programme en changeant des int par des long.

                                                                                                    Tout a fait, maintenant ce que Java fera c'est d'ajouter a sa spec de nouvelles methodes supportant une taille d'entier superieure pour les tableaux et autres, et ca resoudra le probleme, sans rien remettre en cause.
                                                                                              • [^] # Re: Bonne nouvelle

                                                                                                Posté par  . Évalué à 2.

                                                                                                Bon, comme le bouton pertinent ne marche pas (j’ai 20 avis disponibles, un bug?) je te dis merci. :)
                                                                                                • [^] # Re: Bonne nouvelle

                                                                                                  Posté par  . Évalué à 2.

                                                                                                  > Est-ce que ce n'est pas plutôt la culture du "mon langage n'a pas la feature X, du coup je clame qu'il est tellement bien qu'on n'en a pas besoin"?
                                                                                                  Ben non, vu le nombre de programmeurs compétents, s’il y avait un besoin (d’IDE), t’inquiète que les IDE se mettraient à pousser comme des champignons et que un ou deux sortiraient vite du lot.
                                                                                                  D’ailleurs, tu remarqueras que pour Python par exemple, des IDE de très bonne facture existent [http://eric-ide.python-projects.org/], mais sont peu utilisés.
                                                                                                  • [^] # Re: Bonne nouvelle

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

                                                                                                    Ou plus simplement il y a plus d'outils en Java, parce que c'est le langage le plus utilisé...

                                                                                                    Je ne sais pas non plus s'il existe des statistiques sérieuses au sujet de l'utilisation d'IDE chez les pythoneux.

                                                                                                    Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

                                                                                                  • [^] # Re: Bonne nouvelle

                                                                                                    Posté par  . Évalué à 2.

                                                                                                    Heu, calloc(INT_MAX, sizeof(void*)), ça a beau être super crétin, ça a le même sens partout : créer un tableau associant à chaque entier disponible un pointeur. C’est d’ailleurs le même sens que new Object[MAX_INT] en Java.
                                                                                                    Après, ça plantera si t’as pas assez de RAM oui (que tu sois sur un 16 bits avec 20ko de RAM et pas de swap ou un 32 bits avec moins de 4 Go de RAM + swap), mais c’est là une question de capacités de la machine.

                                                                                                    C’est pas parce la taille d’un entier varie que la sémantique derrière change.
                                                                                                    • [^] # Re: Bonne nouvelle

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

                                                                                                      C’est quoi la différence entre « imprévisible » (Java) et « ça dépend » (C++) ? La même qu’entre un bon et un mauvais chasseur ?

                                                                                                      La norme Java impose certaines choses (ordre des initialisations statiques, accès à la mémoire, synchronisation, intéractions entre thread) et il y a une bibliothèque standard pour le threading avec un comportement spécifié.

                                                                                                      En C++, c'est le bordel, chaque combinaison compilateur/plateforme d'exécution/bibliothèque peut avoir un comportement différent.

                                                                                                      Heureusement ça va changer : http://en.wikipedia.org/wiki/C%2B%2B0x#Multitasking_memory_m(...)

                                                                                                      Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

                                                                                                  • [^] # Re: Bonne nouvelle

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

                                                                                                    C'est vrai que c'est tellement utile un malloc(INT_MAX)...

                                                                                                    Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

                                                                                                    • [^] # Re: Bonne nouvelle

                                                                                                      Posté par  . Évalué à 2.

                                                                                                      Quand je regarde Java, je vois un langage ennuyant qui a été conçu uniquement pour les noobs, réduisant au maximum le nombre de choses qu'ils ont à maîtriser.

                                                                                                      DLFP >> PCInpact > Numerama >> LinuxFr.org

                                                                                                      • [^] # Re: Bonne nouvelle

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

                                                                                                        Je suppose donc que je ne peux pas savoir :
                                                                                                        - sur quel OS je tourne, et agir en conséquence
                                                                                                        - l’endianness de la machine hôte, et agir en conséquence (par exemple IPC avec un programme écrit en C++ qui partage ses données dans le sens de la machine hôte)
                                                                                                        - la JVM sur laquelle je tourne, et agir en conséquence

                                                                                                        D'après la norme Java ? non.
                                                                                                        Avec des API dédiés, bien sûr que oui.
                                                                                                        C'est toute la différence : le langage, la JVM, sont normalisés de telle sorte qu'ils sont totalement indépendant de la machine physique, ce qui garantie sa portabilité. Après tu peux utiliser des API qui font autre chose, c'est ton problème mais plus celui de la norme.
                                                                                                    • [^] # Re: Bonne nouvelle

                                                                                                      Posté par  . Évalué à 1.

                                                                                                      Tu vois pas l'utilite de creer un tableau de 64Ko en C sur un systeme qui a 1Mo de RAM et qui peut en addresser 1Mo voire 16 ? Moi oui

                                                                                                      Le probleme est quand ce meme code se met a allouer 2Go sur un systeme qui ne peut en allouer que 4 au grand maximum et qui en realite n'en a que 3 ou 2 de disponible en allocation pour un processus, sans compter ce que le systeme utilise et qui reduit et fragmente la quantite disponible.

                                                                                                      --> Tu passes d'une allocation qui est 16 ou 256x plus petite que l'espace d'addressage, a une qui est 2x plus petite que l'espace d'addressage, et tu passes d'une tres tres grande chance d'avoir une allocation reussie, a quasiment aucune.

                                                                                                      Tu le vois toujours pas le probleme ?

                                                                                                      La difference avec les autres langages, c'est qu'avec eux, ta taille d'allocation ne change pas, elle est constante quel que soit le systeme, des surprises du genre tu n'en as pas, si ton code tourne sur un 80x286 avec 16Mo de RAM, tu sais qu'il tournera sur un P4 avec 2Go de RAM, avec le C ce n'est pas le cas.
                                                                                                      • [^] # Re: Bonne nouvelle

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

                                                                                                        Ben nan, et c’est très précisément ce que je voulais dire.
                                                                                                        C'est totalement idiot comme affirmation. Le passé l'a montré : Java a déjà évolué de nombreuses fois, et si le besoin se fait sentir demain d'indexer un tableau avec un long, aucun doute qu'il évoluera dans ce sens, et ca va pas casser grand chose.

                                                                                                        Si je veux juste "un nombre sur lequel ma machine peut faire des opérations arithmétiques" (l’immense majorité des algos),
                                                                                                        L'immense majorité des algos ont besoins d'être bornés, tu connais beaucoup d'algo générique qui marche quelque soit la taille d'un int ?

                                                                                                        int et int32_t, ce n’est pas _du tout_ la même chose sémantiquement,
                                                                                                        On est d'accord, mais le int existe, est dans la norme, et est beaucoup trop dépendant de la machine pour qu'il soit considéré comme non portable pour la majorité des codes qui l'utilise.

                                                                                                        unsigned int rgbaColor = 0xdeadbeef, c’est une hérésie, que ce soit en C ou en Java
                                                                                                        C'est absolument pas une hérésie en Java, la taille des int est garantie, et tu peux compter dessus.

                                                                                                        Relis mon exemple. Tu ne l’as pas compris.
                                                                                                        Tu essaies de nous démontrer que ca a un intérêt pour un algo de voir ses possibilités décuplés parceque demain la taille de ses pointeurs ou de ses int va augmenter. C'est totalement ridicule.
                                                                                                        Le seul intérêt qu'il y a à manipuler des int, c'est pour une question d'optimisation puisque celà correspond à la taille des données manipulées nativement par l'UC. Ce qui montre bien que celà n'a strictement rien de portable.
                                                                                                        Le C, c'est un compromis entre portabilité et performance.

                                                                                                        il n’y a pas un langage plus ou mois portable qu’un autre entre Java et C
                                                                                                        Bah si : en Java, quelque soit l'architecture sur laquelle tu tournes, ton algorithme aura toujours les mêmes bornes, toujours le même comportement et toujours le même résultat.

                                                                                                        la sémantique générale de l’algorithme multiplyByTwo est préservée
                                                                                                        Si tu définies la sémantique comme étant celle exprimée par la construction syntaxique en C, effectivement elle sera préservée. Le risque, c'est que la sémantique qu'a voulu donner le programmeur avant de le traduire en C, elle peut en prendre un gros coup dans l'aile.
                                                                                                • [^] # Re: Bonne nouvelle

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

                                                                                                  En C# :
                                                                                                  int* fib = stackalloc int[Int32.MaxValue];
                                                                                                  • [^] # Re: Bonne nouvelle

                                                                                                    Posté par  . Évalué à 3.

                                                                                                    java = playmobil
                                                                                                    C = lego

                                                                                                    my 2 cents...
                                                                                                    • [^] # Re: Bonne nouvelle

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

                                                                                                      Combien d'elements maximum peut-il gerer ? MAX_INT ...

                                                                                                      Non. Même les gros noobs savent que int et size_t ne sont pas forcément le même type.

                                                                                                      Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

                                                                                                      • [^] # Re: Bonne nouvelle

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

                                                                                                        le langage est inutilisable

                                                                                                        Alors il faut se demander pourquoi ce langage "inutilisable" est le plus utilisé?

                                                                                                        Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

                                                                                                    • [^] # Re: Bonne nouvelle

                                                                                                      Posté par  . Évalué à 0.

                                                                                                      Merci de confirmer que tu n'as rien d'intelligent a dire
                                                                                                      • [^] # Re: Bonne nouvelle

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

                                                                                                        je regardes pas la theorie de ce que t'es sense faire et que 1% des gens font, mais ce que l'enorme majorite des gens font

                                                                                                        Tu es le seul zoulou à faire des malloc(INT_MAX).

                                                                                                        Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

                                                                                                        • [^] # Re: Bonne nouvelle

                                                                                                          Posté par  . Évalué à 1.

                                                                                                          bref c'est bien pour les boîtes qui emploient des développeurs incompétents et qui veulent limiter la casse. Bref, c'est le côté simpliste de Java qui permet ça, là où dans d'autres langages certaines fonctionnalités rendent l'analyse difficile.

                                                                                                          Cool, t'iras expliquer a Google qu'ils sont incompetents.
                                                                                                          Et t'iras expliquer a Facebook que leur gars qui ont deploye hadoop et leur permettent de gerer un demi millard d'utilisateurs sans broncher sont des incompetents.
                                                                                                          Merci de me traiter d'incompetent aussi, pourtant ma boite sert 20 millions de visiteurs uniques par mois, a se demander comment des incompetents pareils peuvent faire un truc qui marche!

                                                                                                          En somme, si je te suis:
                                                                                                          - Si c'est simple, c'est forcement mal. Probablement que ca ne doit pas brosser ton besoin de te prouver qq chose dans le bon sens.
                                                                                                          - Si c'est complique au point que le tooling devient impossible a implementer alors c'est bien. Forcement, ca doit te permettre de te faire mousser devant tes potes a la fac.

                                                                                                          Et donc:
                                                                                                          Il vaut mieux un truc complique que peu peuvent utiliser et que meme ces peu qui peuvent l'utiliser ont du mal avec parfois.
                                                                                                          Plutot qu'un truc simple que les neuneus peuvent utiliser sans trop de problemes et que les mecs competents peuvent utiliser pour liberer leur temps de cerveau pour faire des applications massives

                                                                                                          Ce qui me fait le plus marrer la dedans, c'est que tu vas probablement venir te gargariser dans un autre thread des concepts unix de base, genre "keep it simple, stupid".

                                                                                                          If you can find a host for me that has a friendly parrot, I will be very very glad. If you can find someone who has a friendly parrot I can visit with, that will be nice too.

                                                                                                • [^] # Re: Bonne nouvelle

                                                                                                  Posté par  . Évalué à 1.

                                                                                                  tu as juste trop de fois "pertinente" ses commentaires. C'est le probleme de troll comme ca. Au bout d'un moment cela part en c... et comme plus personne ne peut "inutile" les messages ce sont les pires moments du trolls qui restent visibles. Exemple tous les messages d'une ligne qui traite les interlocuteurs d'idiots sont bien visibles...
                                                                                                  • [^] # Re: Bonne nouvelle

                                                                                                    Posté par  . Évalué à 0.

                                                                                                    Marrant, parce que de tous les commentaires de cette depeche, il n'y a qu'un commentaire qui contient le mot idiot, et c'est le tien.

                                                                                                    Et ca en dit long sur toi et ton apport a ce fil de discussion et ce site en general.
                                                                                                    • [^] # Re: Bonne nouvelle

                                                                                                      Posté par  . Évalué à 3.

                                                                                                      Peut etre pas si ca se trouve cela fait parti des normes de codage dans sa boite?
                                                                                                      • [^] # Re: Bonne nouvelle

                                                                                                        Posté par  . Évalué à 2.

                                                                                                        Je crois que tu as zappé le mot « sans », qui faisait référence au mot IDE.
                                                                                                        • [^] # Re: Bonne nouvelle

                                                                                                          Posté par  . Évalué à 0.

                                                                                                          D'un autre cote, le development a papa des annees 80 ou on faisait tout avec vi et on compiler a la main, c'est fini, hein.

                                                                                                          Je comprends que ca caresse ton ego de tout faire a la main, mais le but du jeu c'est de produire des applis, pas de se mesurer la quequette a base de ki k'est le plus hardcore.

                                                                                                          Je sais pas c'est un peu comme si tu disais: "les chaines de productions modernes, c'est a chier, un ouvrier peu plus travailler avec simplement un marteau et un tournevis, il lui faut un paquet de machines".

                                                                                                          On s'en fout que Java soit tres aride sans ide, vu que tout le monde d'a peu pres sain d'esprit en utilise un.

                                                                                                          If you can find a host for me that has a friendly parrot, I will be very very glad. If you can find someone who has a friendly parrot I can visit with, that will be nice too.

                                                                                                          • [^] # Re: Bonne nouvelle

                                                                                                            Posté par  . Évalué à 2.

                                                                                                            > Le passé l'a montré : Java a déjà évolué de nombreuses fois
                                                                                                            L’API J2** a évoluée, le langage Java a vu des fonctionnalités ajoutées. Par contre, je n’ai pas vu des fonctionnalités du langage modifiées (ce que serait « bon en fait on s’est planté, les long comme indice d’un tableau, c’est valide… J’aimerais bien voir d’ailleurs comment ils feront pour faire cohabiter les programmes dont le bytecode contient des index de tableaux en int et des index de tableaux en long, mais en même temps je connais pas le bytecode Java). Si tu as des exemples…

                                                                                                            > C'est absolument pas une hérésie en Java
                                                                                                            Si, de la même manière que new int[(int)math.PI] est une hérésie. Pour la n-ième fois, c’est pas parce qu’une constante marche « par hasard » qu’il est correct de l’utiliser. Si le type de ta variable nécessite sémantiquement une taille définie, tu l’explicites, sinon celui qui reprendra le projet dans 5 ans risque de se casser la tête (il voulait juste un nombre ou il voulait un conteneur pour 32 bits ? Je peux utiliser short pour réduire l’emprunte mémoire étant donné que maintenant on stocke des centaines de millions d’éléments ?)

                                                                                                            > tu connais beaucoup d'algo générique qui marche quelque soit la taille d'un int ?
                                                                                                            Heu, tous les algos de base pour la manipulation des structures de données : tables de hashage, graphes & arbres, liste chainées, tableaux, qui en pratique scalent selon la taille du type de base (pointeur pour les liste chainées, entier pour le tableau,…)

                                                                                                            > Tu essaies de nous démontrer que ca a un intérêt pour un algo de voir ses possibilités décuplés parceque demain la taille de ses pointeurs ou de ses int va augmenter. C'est totalement ridicule.
                                                                                                            En quoi c’est ridicule ?
                                                                                                            • [^] # Re: Bonne nouvelle

                                                                                                              Posté par  . Évalué à 2.

                                                                                                              Niveau IDE, Eclipse supporte plein d'autres langages, autocomplétion comprise. (Des fois ça ne marche pas à cause de leur nature trop imprévisible mais on peut lui mettre des indications en commentaire.) Enfin bref, oui ça existe.

                                                                                                              DLFP >> PCInpact > Numerama >> LinuxFr.org

                                                                                                      • [^] # Re: Bonne nouvelle

                                                                                                        Posté par  . Évalué à 3.

                                                                                                        > Tu vois pas l'utilite de creer un tableau de 64Ko en C sur un systeme qui a 1Mo de RAM et qui peut en addresser 1Mo voire 16 ?
                                                                                                        Si je veux créer un tableau de 64 Ko, je fais un malloc(64*1024), pas un malloc(INT_MAX) parce qu’il se trouve que par le plus grand des hasards la constante matche.
                                                                                                        De même, si je devais créer un tableau de 3 éléments, il ne me viendrait pas l’idée un seul instant de faire un new byte[(int)java.math.PI], même si ça fait ce que je veux.
                                                                                                        Parce que bon, tu peux aussi faire un new byte[GetJVMName().getSize()] si par le plus grand des hasards la longueur du nom de ta JVM est pareil que la taille de ton tableau désiré.
                                                                                                        Tu peux.
                                                                                                        Ce sera juste pas portable et totalement crétin.
                                                                                                        • [^] # Re: Bonne nouvelle

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

                                                                                                          L’API J2** a évoluée, le langage Java a vu des fonctionnalités ajoutées. Par contre, je n’ai pas vu des fonctionnalités du langage modifiées
                                                                                                          Bah ca serait un ajout, pas une modification : le compilateur accepterait, en plus de la signature tab[int] la signature tab[long].

                                                                                                          Pour la n-ième fois, c’est pas parce qu’une constante marche « par hasard » qu’il est correct de l’utiliser.
                                                                                                          Ben en Java c'est pas un hasard.

                                                                                                          Si le type de ta variable nécessite sémantiquement une taille définie, tu l’explicites, sinon celui qui reprendra le projet dans 5 ans risque de se casser la tête
                                                                                                          Euh, en même temps t'as une alternative ? La norme Java ne défini pas de type dont le nom comporte le nomber de bits associés.
                                                                                                          C'est le concept même des types "primitifs" : ils sont là pour stocker de l'information, à toi de structurer son accès avec une classe qui encapsule ces données.
                                                                                                          Si t'as peur, tu peux même mettre un commentaire pour le futur.
                                                                                                          Si t'es pas d'accord, propose moi une alternative à cette hérésie en Java pour stocker ta couleur.

                                                                                                          En quoi c’est ridicule ?
                                                                                                          C'est ridicule parcqu'une bonne pratique consiste, quand tu souhaites que ton algo soit indépendant d'un type, à mettre un typedef (à défaut de template ou de généricité).
                                                                                                          Il est sémantiquement idiot, si ton algo se veut indépendant de la taille des données manipulées, de mettre "int" plutôt que "long" ou "patate".
                                                                                                          • [^] # Re: Bonne nouvelle

                                                                                                            Posté par  . Évalué à 2.

                                                                                                            Non. Les gros noobs ne savent même pas forcément ce qu'est size_t, parce que leur prof fait comme 90% des profs et leur fait faire

                                                                                                            int i;
                                                                                                            ...
                                                                                                            for (i = 0; i < n; i++)
                                                                                                            ...


                                                                                                            J'ai enseigné le C système à des élèves de L3, et je crois bien que j'étais le premier à leur faire remarquer qu'il y avait d'autres types entiers (size_t, long, unsigned...) que le simple type int.
                                                                                                            • [^] # Re: Bonne nouvelle

                                                                                                              Posté par  . Évalué à 2.

                                                                                                              > Bah ca serait un ajout, pas une modification : le compilateur accepterait, en plus de la signature tab[int] la signature tab[long].
                                                                                                              Si C++ interdit la surcharge sur la seule base de la taille d’un type numérique, c’est pas pour rien : c’est très casse-gueule.
                                                                                                              Mais bon, je pense (sans ironie) que je ferai mieux de me taire, je connais pas assez le fonctionnement interne des JVM ni même à quoi ressemble le bytecode Java (en dehors que c’est du bytecode).

                                                                                                              > Ben en Java c'est pas un hasard.
                                                                                                              Dans le sens de coïncidence, pas d’aléatoire.

                                                                                                              > La norme Java ne défini pas de type dont le nom comporte le nomber de bits associés.
                                                                                                              J’avais oublié ce détail (une des nombreuses raisons que je fuis Java, pourtant… mais si je devais toutes les retenir… mais on s’éloigne du sujet).
                                                                                                              Effectivement, je vois pas de meilleure solution que d’encapsuler ça dans une classe et de mettre un commentaire.
                                                                                                              • [^] # Re: Bonne nouvelle

                                                                                                                Posté par  . Évalué à 2.

                                                                                                                Le fait que le C soit un langage très très très casse-gueule pour les "noobs", c’est pas une nouveauté hein…
                                                                                                                Il est clair que quelqu’un qui a deux ans de « programmation » (comprendre : un DUT informatique) derrière lui, je le met pas dans un projet en C direct, sauf à mettre quelqu’un qui relit chacune de ses lignes derrière.

                                                                                                                [troll]
                                                                                                                D’ailleurs, c’est pas ça le principe d’un noob fraîchement diplômé, de se charger du code des projets Java-bateau, pour que les personnes plus expérimentées puissent se concentrer sur de vrais projets ?
                                                                                                                [/troll]
                                                                                                  • [^] # Re: Bonne nouvelle

                                                                                                    Posté par  . Évalué à 2.

                                                                                                    Le problème n'est pas lié à la possibilité d'allouer 2 Gio. Bien sûr que c'est faisable. Le problème vient du fait qu'allouer 2 Gio peut prendre un sacré bout de temps à l'exécution. Je te laisse le soin de le faire proprement:


                                                                                                    #define TWO_GIGS 2UL * (1UL << 30)
                                                                                                    int *array = malloc(TWO_GIGS);
                                                                                                    for (size_t i = 0; i < TWO_GIGS; ++i)
                                                                                                        array[i] = i; /* to force memory to be allocated */

                                                                                                    foo(array);


                                                                                                    Définis ensuite foo() quelque part dans une autre unité de compilation, pour être sûr que gcc ne va pas simplifier le code (ou compile avec -O0). Bref. Sur mon super core i7 au boulot, effectivement je risque d'aller très vite. Sur mon Core 2 de l'ancien boulot, ça va prendre un moment. Je le sais d'expérience.
                                                                                                    • [^] # Re: Bonne nouvelle

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

                                                                                                      L'apport de Java par rapport à C/C++ est d'avoir résolu les problèmes suivants :

                                                                                                      - temps de compilation interminable.
                                                                                                      - lib standard anoréxique.
                                                                                                      - comportements non définis ( initialisation statique, accès concurrents...)
                                                                                                      - compatibilité binaire très difficile à maintenir.
                                                                                                      - IDE et outils peu puissants.

                                                                                                      Aujourd'hui un langage qui ne propose pas au moins aussi bien dans chacun de ces domaines ne vaut rien.

                                                                                                      Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

                                                                                                      • [^] # Re: Bonne nouvelle

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

                                                                                                        Vraiment? La signature malloc( size_t ), ça ne leur chatouille pas le bulbe? Et ils essayent tous de faire des malloc(INT_MAX)? Vivons nous vraiment de devs bizarres comme pBpG?

                                                                                                        Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

                                                                                                        • [^] # Re: Bonne nouvelle

                                                                                                          Posté par  . Évalué à 2.

                                                                                                          « Le fait que le C soit un langage très très très casse-gueule pour les "noobs", c’est pas une nouveauté hein… »

                                                                                                          Je ne dis pas ça non plus. Je répondais juste au monsieur en haut qui disait que même un noob sait qu'il existe size_t. Peut-être bien, mais il ne comprend pas forcément (en fait la plupart du temps c'est même certain) comment sont définis les types, sur quels intervalles, pourquoi size_t est utilisé, etc.

                                                                                                          « [troll]
                                                                                                          D’ailleurs, c’est pas ça le principe d’un noob fraîchement diplômé, de se charger du code des projets Java-bateau, pour que les personnes plus expérimentées puissent se concentrer sur de vrais projets ?
                                                                                                          [/troll] »

                                                                                                          Malheureusement si, et ça me désole. C'est pas comme si faire des trucs immondes en Java c'était si dur que ça (je le sais bien, j'ai pratiqué en tant que stagiaire). La seule différence c'est que Java c'est censé être « bloated » de toute manière, donc y'a qu'à rajouter de la RAM au serveur, alors que C c'est censé aller vite donc si ça va pas assez vite, c'est le programmeur qui est en cause.

                                                                                                          ... Alors qu'en pratique un bon dév Java (disons un « expert ») devrait finir par connaître plutôt bien la JVM qu'il utilise, et donc savoir comment son code se traduit en bytecode, etc... Et donc, avoir une connaissance pointue d'une machine virtuelle là où en C on a une machine « concrète ».
                                                                                                      • [^] # Re: Bonne nouvelle

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

                                                                                                        Trouve moi un seul exemple valable du malloc(INT_MAX).

                                                                                                        A part se ridiculiser dans un troll, je ne vois pas :-)

                                                                                                        Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

                                                                                                      • [^] # Re: Bonne nouvelle

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

                                                                                                        Tu le vois toujours pas le probleme ?

                                                                                                        Le problème ici c'est le codeur qui fait une opération débile.

                                                                                                        Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

                                                                                                        • [^] # Re: Bonne nouvelle

                                                                                                          Posté par  . Évalué à 2.

                                                                                                          > temps de compilation interminable.
                                                                                                          Relativement au C, l’écart n’est pas tellement évident sur une machine récente.
                                                                                                          (par rapport à du vrai C++ avec des templates de partout, par contre, je suis à 100% d’accord)

                                                                                                          > accès concurrents...
                                                                                                          Toujours indéfinis en Java, et dans tous les langages que je connais d’ailleurs.

                                                                                                          > IDE et outils peu puissants
                                                                                                          La plupart des IDE « puissants » sont multi-langage. Quant à des outils puissants, liés au langage, qui auraient contribué au succès de Java, je vois pas.
                                                                                  • [^] # Re: Bonne nouvelle

                                                                                    Posté par  . Évalué à 2.

                                                                                    > Je veux lire un fichier dans une structure en memoire et ensuite acceder a une valeur val de taille t dans cette structure situee a offset du debut.
                                                                                    Et en Java, tu fais comment ?
                                                                                    • [^] # Re: Bonne nouvelle

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

                                                                                      "Most people new to Java coming from C think that they need to code differently depending on whether the machine they are using internally represents integers as big or little endian. In Java it does not matter. Further, without resorting to native classes, there is no way you can even tell how they are stored. The JVM may store them either way internally but Java is cleverly constructed so that it never matters."
                                                                                      http://mindprod.com/jgloss/endian.html
                                                                                      • [^] # Re: Bonne nouvelle

                                                                                        Posté par  . Évalué à 2.

                                                                                        Tu n’as pas compris ce que je voulais dire.
                                                                                        Java ne te permet pas de stocker des classes directement dans un fichier (l’équivalent de write(fd, (void*)&myStruct, sizeof(myStruct)). Tu dois passer par une API de sérialisation.
                                                                                        Ben en C, pareil : si tu veux pas te prendre la tête, tu passes par une API de sérialisation. Ce sera plus lourd en C à cause du manque d’introspection, je te l’accorde.
                                                                                        • [^] # Re: Bonne nouvelle

                                                                                          Posté par  . Évalué à 1.

                                                                                          La difference c'est qu'en Java/C#/autre, t'as rien a faire, et en C tout a faire.
                                                                                          • [^] # Re: Bonne nouvelle

                                                                                            Posté par  . Évalué à 2.

                                                                                            Différence d’API, donc, pas de langage.
                                                                                            Si c’est pour dire que .Net/Java a une librairie standard plus fournie, j’étais au courant avant.
                                                                                            • [^] # Re: Bonne nouvelle

                                                                                              Posté par  . Évalué à 1.

                                                                                              Et tu croyais que c'etait quoi d'autre ?

                                                                                              Parce que bon, au final tu peux ecrire une JVM C# ou Java en C, donc en theorie tout ce que tu peux faire en C# / Java tu peux le faire en C, mais faut etre un peu realiste et voir le langage pour ce qu'il est dans un contexte d'utilisation normale.

                                                                                              T'as un soft a ecrire de maniere portable, l'ecrire en Java, C# ou autre Python sera bcp plus facile que l'ecrire en C au niveau portabilite.
                                                                                              • [^] # Re: Bonne nouvelle

                                                                                                Posté par  . Évalué à 3.

                                                                                                En étant un peu réaliste, dans un contexte d’utilisation normale, tu utilises des librairies pour te faciliter la vie, parce que le C n’est pas « battery included ».
                                                                                                • [^] # Re: Bonne nouvelle

                                                                                                  Posté par  . Évalué à 1.

                                                                                                  Tout a fait, le probleme etant de trouver une librairie qui
                                                                                                  a) est disponible sur toutes les plateformes que tu veux
                                                                                                  b) est utilisable du point de vue de la licence

                                                                                                  Avec le framework du langage, c'est simple la question ne se pose pas.

                                                                                                  Avec C, vu qu'il n'y a justement pas de framework, ben faut bien chercher et esperer avoir de la chance.
                                                                                    • [^] # Re: Bonne nouvelle

                                                                                      Posté par  . Évalué à 1.

                                                                                      tu lit 4 byte a l'offset machin et tu te pose pas la question de savoir si la machine qui a ecrit etait big/little endian ni si sa taille d'int est de 16 ou 32 bits.
                                                                                      Et ca marche!

                                                                                      If you can find a host for me that has a friendly parrot, I will be very very glad. If you can find someone who has a friendly parrot I can visit with, that will be nice too.

                                                                                      • [^] # Re: Bonne nouvelle

                                                                                        Posté par  . Évalué à 3.

                                                                                        Heu, la fonction Write(Int32) de .Net (je suppose que c’est pareil en Java), c’est deux lignes à implémenter en C, je vois encore pas la différence.
                                                                                        La difficulté est d’obtenir l’offset en fonction de l’alignement et tout. Tu fais comment en Java, sans les APIs de sérialisation ?
                                                                                        • [^] # Re: Bonne nouvelle

                                                                                          Posté par  . Évalué à 1.

                                                                                          Heu, la fonction Write(Int32) de .Net (je suppose que c’est pareil en Java), c’est deux lignes à implémenter en C, je vois encore pas la différence.

                                                                                          La difference c'est qu'en C, faut penser au fait que ton int ne fait pas necessairement la meme taille partout, et donc au niveau du format standardise sur une certaine taille.
                                                                                          La ou en Java ou C#, tu dit write(int) et read(int).
                                                                                          Ton write(int) en C n'est plus un write(int), mais write4bytes(int).
                                                                                          C'est un exemple simple, mais comme il parait que C est portable, pourquoi est ce qu'on a besoin d'y penser?

                                                                                          Si tu contentes d'outputter ton int de 16 bits et que tu cherches a le lire ensuite sur une machine ou l'int fait 32 bits, tu vas avoir comme qui dirait des soucis.

                                                                                          If you can find a host for me that has a friendly parrot, I will be very very glad. If you can find someone who has a friendly parrot I can visit with, that will be nice too.

                                                                                          • [^] # Re: Bonne nouvelle

                                                                                            Posté par  . Évalué à 1.

                                                                                            enfin c'est quand même bien se prendre la tête sachant que tout le monde utilise des int32_t et consors. Perso j'ai eu plus de problème avec des histoires d'endianess.
                                                                                            • [^] # Re: Bonne nouvelle

                                                                                              Posté par  . Évalué à 2.

                                                                                              En fait il y a plusieurs problemes potentiels:
                                                                                              - endianess
                                                                                              - taille des types int/word/double/etc.
                                                                                              - alignement memoire (si tu veux lire a un offset dans ta structure, selon le compilateur et l'architecture, tu peux avoir un padding different...)

                                                                                              Tout ca est evidemment gerable en C, mais ce qu'on repete depuis le debut, c'est que:
                                                                                              - c'est relativement complique
                                                                                              - cela necessite beaucoup plus de code (ou de se trimballer un framework expres pour comme le font beaucoup de projets portables)
                                                                                              - on doit garder en tete des details d'assez bas niveau si on veut pas se planter
                                                                                              - les gens qui viennent nous expliquer que c'est trivial et que portabilite == respecter la norme ANSI sont de petits rigolos qui n'ont justement jamais eu a ecrire et maintenir du code de ce genre.
                                                                                              • [^] # Re: Bonne nouvelle

                                                                                                Posté par  . Évalué à 2.

                                                                                                > - c'est relativement complique
                                                                                                Si ton but c’est de faire un write((void*)&myStruct) parce qu’on peut le faire et que ça a l’air funton compilateur t’engueulera pas si tu le fais, oui.
                                                                                                Si ton but c’est de faire un truc qui juste marche, non, même en ANSI C : tu spécifies ton format de fichier et tu mets noir sur blanc l’endianness et la taille. Pas de problème d’alignement si tu fais pas un read((void*)&myStruct) mais que tu fais champ par champ. Oui, on sait : Java l’a fait pour toi. Mais la question « battery included » ou pas est orthogonale à la question « portable ou pas »
                                                                                                Et je te signale que tu entres ici dans la question de la portabilité des API, question que tu avais admis toi-même qu’elle était peu pertinente, tellement il est simple de faire non portable dans la communication avec l’extérieur.

                                                                                                > cela necessite beaucoup plus de code
                                                                                                Pas beaucoup non
                                                                                                write32(int32): 2 lignes (1 ligne pour le write, 1 ligne pour le htonl).
                                                                                                int32 read32(): 3 lignes (1 ligne pour le read, 1 ligne pour le ntohl, 1 ligne pour le return).
                                                                                                Le truc vraiment chiant à gérer c’est la représentation des flottants par contre, là je t’accorde que ce sera un peu plus que 5 lignes. Mais ce sera pas 3000 lignes non plus.
                                                                                                Bon, pour faire propre, double le nombre de lignes pour la gestion des erreurs.

                                                                                                > ou de se trimballer un framework expres pour comme le font beaucoup de projets portables
                                                                                                Parce que J2SE, c’est pas un framework peut-être ?
                                                                                                • [^] # Re: Bonne nouvelle

                                                                                                  Posté par  . Évalué à 1.

                                                                                                  Pas de problème d’alignement si tu fais pas un read((void*)&myStruct) mais que tu fais champ par champ.

                                                                                                  Dans mon cas, je dois acceder aux donnees par offset (pour recuperer au choix int32, int16 et byte). Donc meme en lisant les donnees champ par champ lors du chargement depuis le disque, j'ai quand meme des problemes d'alignement lors d'un access ulterieur si je ne fais pas attention et que je ne rajoute pas des #pragma pack autour de ma structure (le padding depend de l'architecture et du compilateur...).

                                                                                                  Mais la question « battery included » ou pas est orthogonale à la question « portable ou pas »

                                                                                                  La question est depuis le debut portable facilement ou pas...
                                                                                                • [^] # Re: Bonne nouvelle

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

                                                                                                  Et je te signale que tu entres ici dans la question de la portabilité des API
                                                                                                  Ce n'est pas un problème d'API : on parle bien de la définition du langage. Le C te permet de par sa grammaire d'obtenir des résulats différents d'une machine à l'autre là où le Java ou C# ne te le permettent pas. Ce n'est pas un comportement différent de l'API : le problème vient bien de la trop forte liaison entre les types primitifs du C avec l'architecture hardware, les I/O fichiers binaires ne sont qu'un révélateur, les API spécialisés en C ne sont là que pour cacher les lacunes natives du langage. Java ou C# n'utilises pas des API pour régler le problème, mais définissent une machine virtuelle qui constitue une véritable abstraction de l'hardware, et ouvre donc la voie à une portabilité totale du code qui le cible. En fait le C# et Java ne sont pas du tout portables : ils ciblent avant tout une seule machine, avec une architecture bien précise. L'astuce consistant en fait à porter cette machine qui est une machine virtuelle pour obtenir la portabilité de tout ce qui tourne au dessus.

                                                                                                  dans la communication avec l’extérieur.
                                                                                                  Peut-on vraiment parler de communication avec l'extérieur ? Le fichier ne voit pas sa structure modifiée lorsque tu le changes de machine. Par contre le comportement de ton programme, si.
                                                                                                  • [^] # Re: Bonne nouvelle

                                                                                                    Posté par  . Évalué à 2.

                                                                                                    > Ce n'est pas un problème d'API : on parle bien de la définition du langage
                                                                                                    Ben si, la preuve : tu as des APIs en dehors de la librairie standard pour te faire de la serialisation. Toujours pas aussi simple à utiliser qu’en Java, certes, mais ça a plus à voir avec l’absence d’introspection.

                                                                                                    > Ce n'est pas un comportement différent de l'API
                                                                                                    Ben si.
                                                                                                    Avec la librairie standard du C, tu peux écrire tout et n’importe quoi librement. Et si un programme essaie de lire au petit bonheur la chance un truc écrit au petit bonheur la chance par un autre programme, ça a effectivement de fortes chances de pas bien se passer. Pour que ça fonctionne, tu dois définir correctement le format d’échange (endianness, taille des entiers, format des string, format des flottants,…). C’est quelque chose que les ingénieurs de Sun ont fait quand ils ont défini l’API de sérialisation, c’est quelque chose que C s’est refusé à faire (parce que c’est pas son boulot de faire des trucs haut niveau, parce que C a besoin de communiquer avec du non-C, et surement d’autres raisons que j’ignore).
                                                                                                    C’est pareil en Java : si tu essaies de faire un dump mémoire dans un fichier et de reloader brutalement ce dump mémoire sur une autre architecture, il y a de fortes chances que ça marche pas. La différence entre C et Java, c’est que le premier t’autorise à faire ça (en cohérence avec sa philosophie : le langage est pas là pour penser à la place du programmeur, et il y a des situations où faire une telle chose est tout à fait correct) et que le second ne t’y autorisera jamais.
                                                                                                    Objective-C, en tant que langage, est exactement dans la même situation que le C à ce niveau (taille de l’entier qui varie, endianness, alignement, etc). Pourtant, OpenStep/Cococa a défini une API et un format d’échange, comme Java, et bizarrement, on ne voit personne pour pleurer sur la non-portabilité d’Objective-C et des plist.
                                                                                                    Non, franchement, dire que le C n’est pas portable sous le prétexte que je peux pas charger brutalement le contenu brut de la mémoire d’une architecture vers l’autre (ce que tu fais quand tu fais un write+read direct de tes structures, hein), c’est un peu pareil que dire que Java n’est pas portable parce que je peux pas faire un core dump d’un programme tournant sur la JVM sun et charger ce core dump dans une autre JVM et que le programme puisse continuer sans rien remarquer.
                                                                                                    tl;dr : quel que soit le langage, si tu veux être portable, tu dois définir un format d’échange, la seule différence entre Java et C étant qu’en Java tu as un format défini direct dans l’API standard.

                                                                                                    > Peut-on vraiment parler de communication avec l'extérieur ?
                                                                                                    Ben oui, quand tu communiques avec quelqu’un d’autre que toi (toi = fork(), en gros), tu dois faire gaffe : définir un format d’échange, et ne pas te contenter de lui balancer un dump mémoire à la gueule en le laissant se démerder. Si Java n’a pas ce problème, c’est parce qu’il n’autorise tout simplement pas à balancer un dump mémoire ([troll]c’est la résolution des problèmes selon Java : si une fonctionnalité peut potentiellement être mal utilisée, on la supprime[/troll])
                                                                                                    • [^] # Re: Bonne nouvelle

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

                                                                                                      tu as des APIs en dehors de la librairie standard pour te faire de la serialisation
                                                                                                      On s'en fou, t'es pas obligé de les utiliser, tu peux faire ta propre sérialisation si ça t'excite.
                                                                                                      Ce qui importe, c'est que les API de sérialisation peuvent faire confiance à la JVM qui te garantie l'endianess, la taille des types primitifs, l'alignement : ces API seront portables.
                                                                                                      En C, les API sont obligés de faire du cas par cas en fonction de la plateforme cible.

                                                                                                      Et si un programme essaie de lire au petit bonheur la chance un truc écrit au petit bonheur la chance par un autre programme,
                                                                                                      On te parle d'un même programme, le même code source, mais sur 2 plateformes différentes : le programme ne pondra pas le même binaire et ne lira pas le binaire de la même façon. C'est bien un problème de portabilité du code qui a des comportements différents suivant la plateforme sur laquelle il est compilé/exécuté.

                                                                                                      si tu essaies de faire un dump mémoire dans un fichier et de reloader brutalement ce dump mémoire sur une autre architecture, il y a de fortes chances que ça marche pas
                                                                                                      Le langage/la JVM ne te permet pas de le faire, justement parcque ce n'est pas portable : Java ne t'autorise qu'à faire des trucs portables là où le C te permet de faire des trucs non portables.

                                                                                                      c’est la résolution des problèmes selon Java : si une fonctionnalité peut potentiellement être mal utilisée, on la supprime
                                                                                                      Bah oui, c'est ce qui permet d'obtenir des garanties en terme de portabilité, de sécurité. Au détriments d'autres aspects on est d'accord.
                                                                                                      • [^] # Re: Bonne nouvelle

                                                                                                        Posté par  . Évalué à 2.

                                                                                                        > Java ne t'autorise qu'à faire des trucs portables là où le C te permet de faire des trucs non portables.
                                                                                                        Ce qui ne revient pas au même que de dire que le C n’est pas portable, nom d’une pipe en bois !
                                                                                                        Encore une fois, c’est pas parce que Java n’est pas un langage à preuve formelle qu’il ne permet pas de créer des programmes corrects… si tu fais gaffe.
                                                                                                        Si c’est juste pour dire que le C est un langage beaucoup, beaucoup moins neuneu-proof que Java, je suis d’accord.
                                                                                                        • [^] # Re: Bonne nouvelle

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

                                                                                                          Ce qui ne revient pas au même que de dire que le C n’est pas portable, nom d’une pipe en bois !
                                                                                                          Je crois qu'au fond on est d'accord, le problème c'est que le commentaire initiale qui a conduit à cette dicussion disait explicitement que tout code écrit en C était portable, ce qui est largement faux, bien au contraire. Il faut mieux se dire : le C n'est pas portable, j'ai intérêt de faire gaffe à éviter toutes les constructions du langage qui ne le sont pas si je veux un code indépendant de la machine ; que de croire, comme l'exposait nicolas, ce que lui ont dit ses professeurs : "le C est portable, il a été conçu pour, j'ai jamais eu de problème, donc c'est vrai".

                                                                                                          Si c’est juste pour dire que le C est un langage beaucoup, beaucoup moins neuneu-proof que Java, je suis d’accord.
                                                                                                          C'est plutôt pour dire : warning, si vous voulez faire du code portable, le C n'est pas forcement le plus adapté car il demande un certain nombre d'effort pour y arriver, sans aucune garantie au final, d'autres langages t'offre des garanties et ont vraiment été conçu dans ce sens.

                                                                                                          Sans parler du fait qu'on parle d'une seule forme de portabilité, celle du source : le langage C implique pourtant la compilation dans un binaire qui n'est pas portable, qui ne garantie pas l'interopérabilité binaire entre compilateurs, etc. Autant de problématiques plus ou moins liées qui ont conduit à la création de langages comme Java ou C# : de vrais abstractions du matériel (avec d'autres inconvénients on est d'accord).
                                                                                                          • [^] # Re: Bonne nouvelle

                                                                                                            Posté par  . Évalué à 3.

                                                                                                            Je crois effectivement qu’on est juste pas d’accord sur une question de terminologie : pour toi, un langage pas portable, c’est un langage qui offre des garanties de portabilité, tandis que pour moi c’est un langage qui permet d’être portable (à l’inverse, au pif, de l’assembleur).
                                                                  • [^] # Re: Bonne nouvelle

                                                                    Posté par  . Évalué à 2.

                                                                    > Genre ton soft qui faisait des allocations de 64Ko, maintenant risque d'en faire de 4Go
                                                                    En même temps, si tu t’amuses à faire des malloc(-1), je suis pas sûr qu’on puisse dire que ce soit la faute du langage si ça te pète à la gueule.
                                                                • [^] # Re: Bonne nouvelle

                                                                  Posté par  . Évalué à 1.

                                                                  Quelles sont les repercussions de cette d'int variable sur, disons, la serialization d'un struct?
                                                                  Et la, t'as beau utiliser sizeof, bonne chance pour t'en sortir.

                                                                  If you can find a host for me that has a friendly parrot, I will be very very glad. If you can find someone who has a friendly parrot I can visit with, that will be nice too.

                                                                • [^] # Re: Bonne nouvelle

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

                                                                  Je te parles pas de bugs qui peuvent effectivement survenir si on utilise pas les bonnes constantes : je te parle tout simplement de comportement différents, et donc pas forcement prévu, d'une plateforme à l'autre : cela donne un code qui n'est pas portable, puisque par définition avec un comportement différent.
                                                                  Imagine que tu codes un logiciel qui a une feature dont la capacité dépend d'un int : tu vas dire à ton client "oui bah euh cette fonctionnalité dépend de la machine sur laquelle vous exécuter le logiciel... J'ai un tableau à 6 colonnes et 8 lignes pour les différentes situations si vous voulez".
                                                                  INT_MAX ne change rien au problème : sa valeur diffère elle aussi d'une plateforme à l'autre.
                                                                  En Java ou en C#, Integer.MAX_VALUE ou Int32.MaxValue sont des constantes qui ont toujours les mêmes valeurs, sur toutes les plateformes : bref le code associé aura toujours le même comportement et le résultat sera prévisible : le code est bien portable.
                                                                  Pour celà, ces langages définissent une véritable abstraction de la machine physique, une machine virtuelle. Le C, par définition, autorise les optimisations bas-niveau qui dépendent du hardware : le C n'offre pas, par définition, la garantie d'un code portable, c'est au codeur de s'en assurer.
                                                                  • [^] # Re: Bonne nouvelle

                                                                    Posté par  . Évalué à 2.

                                                                    > tu vas dire à ton client "oui bah euh cette fonctionnalité dépend de la machine sur laquelle vous exécuter le logiciel...
                                                                    Ha, parce que évidemment, dans le monde .Net/Java, on entend jamais « votre machine là, elle est pas assez puissante pour faire tourner cette fonctionnalité ».

                                                                    > sa valeur diffère elle aussi d'une plateforme à l'autre.
                                                                    Ben oui, évidemment, si tu fais un srand(INT_MAX) et que ton logiciel dépend des nombres sortis par ton peudo-RNG, sûr que le comportement diffèrera d’une plateforme à l’autre.
                                                                    En dehors de ce cas, j’ai quelque difficultés à voir un code qui change ses fonctionnalités du tout au tout selon la valeur de INT_MAX (et sans erreur de programmation « mais non c’est du code tout à fait normal » à la malloc(INT_MAX)). Mais peut-être est-ce juste mon manque d’imagination ?
                                                                    • [^] # Re: Bonne nouvelle

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

                                                                      votre machine là, elle est pas assez puissante pour faire tourner cette fonctionnalité
                                                                      Vaguement drôle, mais y dit qu'il voit pas le rapport.

                                                                      Mais peut-être est-ce juste mon manque d’imagination ?
                                                                      Je me suis fait chier à pondre des liens plus haut sur les bonnes pratiques en matière de portabilité du code C, avec des exemples concrêts.
                                                                      Si t'as pas d'imagination, google est ton ami, exemples :
                                                                      http://webcache.googleusercontent.com/search?q=cache:liqP32f(...)
                                                                      http://docs.hp.com/en/5921/portability.html
                                                                      • [^] # Re: Bonne nouvelle

                                                                        Posté par  . Évalué à 2.

                                                                        > Vaguement drôle, mais y dit qu'il voit pas le rapport.
                                                                        Le rapport, c’est qu’à part la quantité de données que sera capable d’ingurgiter le programme, je vois pas ce que la taille des entiers change au niveau fonctionnel.

                                                                        > Si t'as pas d'imagination, google est ton ami, exemples :
                                                                        Ceci ne sont pas des exemples de fonctionnalités qui changent selon la taille d’un entier. Ce sont des listes de bonnes pratiques. Comme il y en a dans tous les langages — si tu les suis pas, vient pas pleurer si ton programme te pète dans les mains.
                                                                        Encore une fois, ce que je te demande, c’est une fonctionnalité bien codée dont le comportement dépend de la taille d’un entier. Parce que si c’est juste pour dire qu’on peut faire du code pas portable en C en faisant n’importe quoi (genre caster un int en pointeur et vice versa), on était au courant, merci.
                                                                        • [^] # Re: Bonne nouvelle

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

                                                                          Le rapport, c’est qu’à part la quantité de données que sera capable d’ingurgiter le programme,, je vois pas ce que la taille des entiers change au niveau fonctionnel.
                                                                          Bah c'est déjà un gros changement... Et je vois toujours pas le rapport avec les limitations de ressource mémoire disponible.

                                                                          Ce sont des listes de bonnes pratiques. Comme il y en a dans tous les langages — si tu les suis pas, vient pas pleurer si ton programme te pète dans les mains.
                                                                          Trouves moi un guide qui parle de portabilité de code Java (qui parle du langage, pas d'API spécifiques style accès au système de fichier).

                                                                          C'est quand même fort : "le code ANSI C est toujours portable" et après "évidemment faut suivre des bonnes pratiques sinon faut pas venir pleurer".

                                                                          Encore une fois, ce que je te demande, c’est une fonctionnalité bien codée dont le comportement dépend de la taille d’un entier.
                                                                          Evidemment ta question est tourné à ta façon : si je trouve un exemple, tu vas dire que la fonctionnalité est mal codée. Tu ne fais que justifier ce que je dis depuis le début : en C, la portabilité du code dépend de la compétence du développeur car la norme en soit ne garantie pas un code portable, au contraire d'un code Java par exemple.

                                                                          Après tout, on peut aussi dire que le C est un langage à typage fort : après tout, si y'a des erreurs de typage, c'est parcque le programmeur il code comme les pieds.

                                                                          Après tout, on peut aussi dire que le C est un langage totalement secure : si y'a des débordements de tampon ou des dereferencement de pointeurs null, c'est la faute au programmeur, il a qu'a bien coder.
                                                                          • [^] # Re: Bonne nouvelle

                                                                            Posté par  . Évalué à 2.

                                                                            > le code ANSI C est toujours portable
                                                                            J’ai une mauvaise nouvelle à t’annoncer : depuis le début, tu te bats contre un homme de paille.
                                                                            Qui ici a dit que le C était toujours portable ?

                                                                            > si je trouve un exemple, tu vas dire que la fonctionnalité est mal codée.
                                                                            Ben voyons. Dire que caster les void* en int et vice-versa c’est mal coder (c’est un des premiers exemple de ton lien), c’est être de mauvaise foi ?
                                                                            J’en déduis donc que chez toi c’est une bonne pratique de caster les pointeurs en entier ?

                                                                            > car la norme en soit ne garantie pas un code portable
                                                                            Je crois que tu n’as pas compris un truc. C est un langage qui a comme principe d’être très laxiste, qui t’autorise à faire d’énorme conneries. Java est un langage au contraire beaucoup plus strict. Donc oui, tu peux faire d’énormes conneries qui t’empêcheront d’être portables en C et pas en Java. De là à dire qu’un programme écrit normalement en C n’est pas portable, il y a un gouffre que je ne peux voir franchi sans réagir.
                                                                            Je vais te faire une image : Java ne peut pas te garantir formellement que ton programme est conforme à sa spécification (le C ne peut te garantir la portabilité), contrairement à certains langages issus de la recherche. Quelle est la bonne chose à en déduire ?
                                                                            - Java ne permet pas de faire du code correct (le C n’est pas portable)
                                                                            - Si tu veux réussir à remplir ton cahier des charges, il faut suivre des bonnes pratiques (si tu veux être portable, il faut suive des bonnes pratiques)
                                                                            • [^] # Re: Bonne nouvelle

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

                                                                              Qui ici a dit que le C était toujours portable ?
                                                                              Toi je sais pas, mais nicolas:
                                                                              "Quand j’écris un code ANSI C il doit tourner et rendre le même résultat quelque soit la machine le supportant"
                                                                              Ou encore :
                                                                              "Le C est portable, oui,"
                                                                              "parce que précisément le C est portable"

                                                                              - Java ne permet pas de faire du code correct (le C n’est pas portable)
                                                                              J'ai jamais dit que le C ne permettait pas de faire du code portable.
                                                                              si tu veux être portable, il faut suive des bonnes pratiques
                                                                              En C oui, en Java, non. (je parle strictement du langage).
                                                                • [^] # Re: Bonne nouvelle

                                                                  Posté par  . Évalué à 2.

                                                                  « int a une taille minimal : 16 bits »

                                                                  Tu es sûr de toi ? Si je regarde la norme, je ne vois qu'une relation d'ordre entre les types, et c'est tout:

                                                                  char <= short <= int <= long
                                                                  sizeof(char) == 1 (même quand un char tient sur 16 bits)

                                                                  Si ensuite tu rajoutes la norme POSIX (toujours dans mes souvenirs), alors

                                                                  sizeof(long) == sizeof(mot mémoire) == sizeof(void *)
                                                                  sizeof(int) >= 32 bits
                                                                  • [^] # Re: Bonne nouvelle

                                                                    Posté par  . Évalué à 2.

                                                                    Oui, je l’ai vu passé à l’occasion de cette « discussion » (au moins elle aura servi à quelque chose ^^) dans Wikipedia, y’a le lien vers la norme en ASCII :

                                                                    « 2.2.4.2 Numerical limits

                                                                    A conforming implementation shall document all the limits specified
                                                                    in this section, which shall be specified in the headers <limits.h>
                                                                    and <float.h> .

                                                                    "Sizes of integral types <limits.h>"

                                                                    The values given below shall be replaced by constant expressions
                                                                    suitable for use in #if preprocessing directives. Their
                                                                    implementation-defined values shall be equal or greater in magnitude
                                                                    (absolute value) to those shown, with the same sign.

                                                                    [...]

                                                                    * maximum value for an object of type int
                                                                    INT_MAX +32767 »
                                                              • [^] # Re: Bonne nouvelle

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

                                                                Quand tu codes en Java, tu espères très fort tomber sur une machine virtuelle et un runtime compatible avec ton binaire...
                                                                • [^] # Re: Bonne nouvelle

                                                                  Posté par  . Évalué à -1.

                                                                  ca va, a moins de deployer sur une jvm de 1998 avec java 1.2, on a en general un jvm 1.6 a dispo, qui fait tourner tout le code java ecrit dans les 20 dernieres annees.

                                                                  If you can find a host for me that has a friendly parrot, I will be very very glad. If you can find someone who has a friendly parrot I can visit with, that will be nice too.

                                                                  • [^] # Re: Bonne nouvelle

                                                                    Posté par  . Évalué à 3.

                                                                    • [^] # Re: Bonne nouvelle

                                                                      Posté par  . Évalué à 2.

                                                                      ???
                                                                      Oui, et?

                                                                      Si tu veux des urls sans rapport avec le sujet, ya un randomizer sur la home page de wikipedia.

                                                                      If you can find a host for me that has a friendly parrot, I will be very very glad. If you can find someone who has a friendly parrot I can visit with, that will be nice too.

                                                                      • [^] # Re: Bonne nouvelle

                                                                        Posté par  . Évalué à 3.

                                                                        C’est vrai que ça tombe un peu comme un cheveu sur la soupe, mais sa remarque est pertinente : combien d’architectures supportées par la JVM, par .Net ? Parce que c’est bien beau de dire : c’est portable, yaka coder une implémentation de CLR/Java bytecode, en pratique, ça donne quoi ?
                                                                        Personnellement, en C, je peux faire du code qui tourne sans modification sur mon PC et le MSP430 (je l’utilise pour faire des routines que je peux tester sur mon PC, c’est plus simple de débugger sur un PC que sur un MSP430). Java, il tourne sur un MSP430 ?
                                                                        • [^] # Re: Bonne nouvelle

                                                                          Posté par  . Évalué à -1.

                                                                          Ca devient du grand n'importe quoi la...

                                                                          Le code machine, ca tourne partout, par definition, donc le code machine est le langage le plus portable au monde?

                                                                          If you can find a host for me that has a friendly parrot, I will be very very glad. If you can find someone who has a friendly parrot I can visit with, that will be nice too.

                                                                          • [^] # Re: Bonne nouvelle

                                                                            Posté par  . Évalué à 3.

                                                                            > Le code machine, ca tourne partout, par definition
                                                                            On a trouvé une fortune plus grosse que le malloc(INT_MAX) de pBpG là !
                                                                            Le code machine ne tourne pas partout, non (que ce soit l’assembleur ou le code binaire résultant), et c’est précisément pour cette raison que deux gus dans leur garage (Dennis Ritchie et Kenneth Thompson) ont inventé un langage portable qui puisse être traduit dans ces langages non-portables.

                                                                            > Ca devient du grand n'importe quoi la...
                                                                            Je confirme. Je ne sais pas d’où m’est venue cette idée saugrenue que la portabilité pouvait avoir un vague rapport lointain avec le fait de pouvoir faire fonctionner le même code source sans modification sur deux architectures aussi différentes que le x86-64 et le MSP430, vraiment.
                                                                            Désolé de t’avoir faire perdre ton temps avec une idée aussi stupide.
                                                                            Sur ce, excuse-moi, mais je dois aller modifier mon dictionnaire pour redéfinir « portable » comme « langage tournant sur une machine virtuelle, mais impossible à faire tourner sur une architecture sur laquelle ladite machine virtuelle n’existe pas ».
                                                                  • [^] # Re: Bonne nouvelle

                                                                    Posté par  . Évalué à 3.

                                                                    ca va, a moins de deployer sur une jvm de 1998 avec java 1.2, on a en general un jvm 1.6 a dispo, qui fait tourner tout le code java ecrit dans les 20 dernieres annees. [

                                                                    Malheureusement c'est faux. Au boulot, j'utilise pas moins de 3 JVM différentes (Sun/Oracle, IBM et Microsoft) et les applis qui fonctionnent sur une des JVM ne fonctionnent pas sur les deux autres. C'est très commode.
                                                      • [^] # Re: Bonne nouvelle

                                                        Posté par  (site web personnel, Mastodon) . Évalué à 5.

                                                        que le systeme A lance une exception en cas d'acces non-aligne alors que le systeme B ne le fait pas, ...

                                                        Là, ce n'est clairement pas la faute du C, c'est juste que l'application a été écrite avec les pieds, et même peut-être en gardant les charentaises.
                                                        • [^] # Re: Bonne nouvelle

                                                          Posté par  . Évalué à -1.

                                                          C'est pas "la faute du C", simplement parce que le C n'a jamais ete concu pour proteger de cela, il n'a pas ete ecrit pour faire du code multiplateforme.

                                                          C'est la difference entre le C, ou le developpeur doit faire des pieds et des mains pour que le code tourne correctement sur plusieurs systemes differents, et des dizaines d'autres langages (Ada, C#, Java, Python, Pascal, ...) ou ce genre de probleme n'existe tout simplement pas.
                                                          • [^] # Re: Bonne nouvelle

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

                                                            simplement parce que le C n'a jamais ete concu pour proteger de cela, il n'a pas ete ecrit pour faire du code multiplateforme.

                                                            Ah ah ah !

                                                            Je juste lole et me rotf-myself-ise !

                                                            Figures-toi que le C a justement été conçu pour porter Unix sur des plateformes diverses et variées, alors bon, camembert !!!
                                                            • [^] # Re: Bonne nouvelle

                                                              Posté par  . Évalué à 1.

                                                              Reprends tes cours d'histoire informatique mon cher. C a ete cree pour simplifier le portage d'Unix oui, mais pour remplacer assembleur, qui est vraiment le pire d'ou on puisse partir. C n'a jamais ete concu pour etre le langage multi-plateforme parfait. Le but etait de simplifier le portag(ce qui n'etait pas dur vu d'ou ils partaient) e tout en ayant un portage efficace.

                                                              C n'a jamais ete cree pour etre totalement multiplateforme comme nombre d'autres langages, et la preuve flagrante est justement ces differences d'implementation du langage d'un systeme a l'autre.

                                                              Typiqument un int de taille different d'une plateforme a l'autre, un pointeur d'une taille differente d'une plateforme a l'autre, ces problemes d'alignement d'une plateforme a l'autre, etc...

                                                              Oui il y a toujours un moyen de faire la chose de maniere multi-plateforme (#define, ne pas oublier d'utiliser sizeof, etc...) mais au final, c'est du boulot en plus pour le developpeur, il faut qu'il connaisse, la ou nombre d'autres langages n'ont absolument pas ce besoin d'attention.
                                                              • [^] # Re: Bonne nouvelle

                                                                Posté par  . Évalué à 2.

                                                                « Oui il y a toujours un moyen de faire la chose de maniere multi-plateforme (#define, ne pas oublier d'utiliser sizeof, etc...) mais au final, c'est du boulot en plus pour le developpeur »

                                                                ⇒ Fortune ! :D
                                                  • [^] # Re: Bonne nouvelle

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

                                                    Il n'y a aucun FUD la dedans, Mono est couvert par une promesse de MS sur les brevets

                                                    Et s'ils mentent, ils vont enfer!

                                                    Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

                                                    • [^] # Re: Bonne nouvelle

                                                      Posté par  . Évalué à 2.

                                                      Non, le juge les enverra chier, vu que c'est contractuel.
                                                      • [^] # Re: Bonne nouvelle

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

                                                        C'est une promesse ou un contrat?

                                                        Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

                                                        • [^] # Re: Bonne nouvelle

                                                          Posté par  . Évalué à 2.

                                                          Je pense que cela a ete dit et ecrit officiellement donc doit etre considere comme un contrat au niveau de la loi.

                                                          Mais cela ne couvre QUE les implementations de C#/.NET tel que decrit dans la norme ECMA c'est a dire 2 ou 3 generations derrieres les versions actuelles...
                                                          • [^] # Re: Bonne nouvelle

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

                                                            Je pense que cela a ete dit et ecrit officiellement donc doit etre considere comme un contrat au niveau de la loi.

                                                            Ce n'est pas du tout évident. Existe-t-il seulement un texte de loi qui réglemente les promesses publiques?

                                                            Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

                                                            • [^] # Re: Bonne nouvelle

                                                              Posté par  . Évalué à 1.

                                                              Le probleme ne pouvant se poser qu'aux states il faut regarder de ce cote la mais je suis presque sur que oui. Et de tout de facon qu'est ce qu'une licence si ce n'est une promesse? Apres elles peuvent respecter ou pas la loi mais je suis presque sur que si la licence dit "on ne poursuit pas si utilisation de nos technos" la loi n'a rien a dire contre. La ou cela peut etre problematique c'est sur les limites de la promesse.
                                                              • [^] # Re: Bonne nouvelle

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

                                                                Bref les promesses s'envolent et les licences restent.

                                                                Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

                                                              • [^] # Re: Bonne nouvelle

                                                                Posté par  . Évalué à 2.

                                                                > Et de tout de facon qu'est ce qu'une licence si ce n'est une promesse?
                                                                Non, ce n’est pas la même chose. Une licence est une contrat entre deux parties, une promesse publique n’implique pas d’autre partie au moment de son énoncé.
                                                                Après, je sais pas quelles sont les implications juridiques :)
                                                            • [^] # Re: Bonne nouvelle

                                                              Posté par  . Évalué à 1.

                                                              Oui.
                                                              Ca depend potentiellement des etats, mais en californie un contrat oral a la meme valeur qu'un contrat ecrit.
                                                              Reste a prouver la parole, mais dans ce cas, ca va etre facile.

                                                              If you can find a host for me that has a friendly parrot, I will be very very glad. If you can find someone who has a friendly parrot I can visit with, that will be nice too.

                                                • [^] # Re: Bonne nouvelle

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

                                                  Que fait la Mono ? Suivre la norme… bien… mais on perd, encore une fois, toute compatibilité avec la référence, et donc le risque de perdre la très grande majorité des programmes ou développeurs qui se soucient peu de la compatibilité.
                                                  Tiens on va prendre un exemple d'un langage qui s'écarte de la norme : Vala. Il est largement inspiré de la norme C#, et s'en écarte sensiblement sur certains points. Est-ce que celà gène ses utilisateurs ? Est-ce que les gens crient au FUD des brevets alors que justement Vala n'est pas protégé n'implémentant explicitement pas la norme ? Est-ce que ce langage perd de son intérêt ?
                                                  • [^] # Re: Bonne nouvelle

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

                                                    Vala s'inspire juste de la syntaxe de C# qui lui même s'inspire de celle de Java qui lui même s'inspire de C++, etc...

                                                    C'est le seul lien, le reste est très différent, contrairement à Mono.

                                                    Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

                                                    • [^] # Re: Bonne nouvelle

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

                                                      Vala s'inspire juste de la syntaxe de C#
                                                      Oui bah on parle de langage, c'est donc l'essentiel.
                                                      Et ma comparaison reste valable : si demain MS sort une version de C# qui sux, Mono peut "forker" et faire son bonhomme de chemin comme le fait Vala, ça lui enlèvera sans doute un intérêt mais la plateforme restera pertinente comme l'est Vala.
                                            • [^] # Re: Bonne nouvelle

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

                                              On s'en branle total : si demain MS impose des trucs totalement débile dans C#, c'est leur problème : si Mono juge que c'est inutile d'aller dans cette direction, rien ne les obligent à suivre MS.
                                              Mono est un logiciel libre, tu peux forker et faire ce que tu veux avec.
                                          • [^] # Re: Bonne nouvelle

                                            Posté par  . Évalué à 1.


                                            > a) C'est un langage sorti tout droit d'une entreprise dont la reputation niveau compatibilite avec l'ancien n'est plus a faire, personne n'arrive a notre
                                            > cheville sur ce sujet

                                            C'est vrai que question compatibilité avec l'ancien Microsoft sait faire. Au hasard, MsWordX avec MsWordX+1 ou X+2 ?
                                            • [^] # Re: Bonne nouvelle

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

                                              Il parle de la compatiblité avec l'ancien. Et ce qui est sûr, c'est qu'Office 2010 a beaucoup plus de chance d'ouvrir un doc rédigé sous Office 97 sans encombre que OpenOffice 3 d'ouvrir un document texte rédigé avec OpenOffice 1.
                                              Donc oui, même si c'est pas parfait, la compatibilité avec l'ancien est sans doute la préocupation majeure de MS, ce qui est d'ailleur un avantage et un inconvénient: maintient de vieilles API avec ce que celà implique en terme de sécurité, maintient de vieilles interfaces, avec ce que celà implique en terme de modernité, lourdeur dans les process de conception/développement (je suppose) pour tenter d'innover tout en gardant la compatibilité, etc.
                                            • [^] # Re: Bonne nouvelle

                                              Posté par  . Évalué à 1.

                                              Oui cela aussi, va t'amuser a passer des fichiers entre les differentes releases d'OpenOffice, ca devient vite rigolo(cf. http://user.services.openoffice.org/en/forum/viewtopic.php?f(...) pour un exemple). Tu peux meme aller leur demander ce qu'ils pensent de la compatibilite ascendante chez MS si tu veux : http://blogs.sun.com/GullFOSS/entry/breaking_a_lance_for_bac(...)

                                              Word 2010 t'ouvres toujours un fichier de Word d'il y a 15 ans avec une representation correcte si ce n'est parfaite.
                                              Va essayer d'en faire de meme avec les autres softs du secteur, bon il est vrai que la majorite d'entre eux n'existaient meme pas il y a 15 ans...
                                              • [^] # Re: Bonne nouvelle

                                                Posté par  . Évalué à 3.


                                                > Word 2010 t'ouvres toujours un fichier de Word d'il y a 15 ans avec une representation correcte si ce n'est parfaite.

                                                Étonnant j'ai souvent entendu dire l'inverse.


                                                > Va essayer d'en faire de meme avec les autres softs du secteur, bon il est vrai que la majorite d'entre eux n'existaient meme pas il y a 15 ans...

                                                Un document latex écrit avec emacs a toujours le même rendu, merci bien.
                                                • [^] # Re: Bonne nouvelle

                                                  Posté par  . Évalué à 2.

                                                  Étonnant j'ai souvent entendu dire l'inverse.

                                                  Il y a la realite (il le fait tres bien, avec quelques problemes de temps en temps quand meme, il y a des bugs chez tout le monde), et le mythe repandu chez nos amis linuxiens qui ont tendance a ne pas comprendre comment un soft fonctionne et tout mettre sur le dos de MS(hint: le rendu depend de l'imprimante notamment)

                                                  Un document latex écrit avec emacs a toujours le même rendu, merci bien.

                                                  Elle est bonne celle-la...

                                                  Latex 2 est sorti en 1994, Latex 3 ? Toujours pas sorti...
                                                  • [^] # Re: Bonne nouvelle

                                                    Posté par  . Évalué à 2.

                                                    Tu changes l’argument, question compatibilité avec l’ancien LaTeX, pour ne pas parler de TeX, bat n’importe quel logiciel de traitement de texte à plate couture. Tu ne peut pas non plus lui reprocher de ne pas évoluer, ce n’est pas la faute à Knuth, et ce n’est pas faute d’essayer : « Donald Knuth offers monetary awards to people who find and report a bug in TeX. »

                                                    On s’en tape de la date de sortie du logiciel !
                                                    • [^] # Re: Bonne nouvelle

                                                      Posté par  . Évalué à 2.

                                                      Tu veux comparer comment la compatibilite ascendante d'un soft sans comparer plusieurs versions ? T'as une technique magique ?

                                                      Resultat, si il n'y a pas plusieurs versions --> Impossible de comparer la compatibilite ascendante.

                                                      Sinon, une nouvelle version c'est pas simplement pour corriger des bugs hein, c'est aussi souvent pour rajouter des features et changer des trucs qui auraient pu etre fait de meilleure maniere.

                                                      Note que je trouves LaTeX super comme soft, il fait ce qu'il est sense faire tres tres bien, mais dans cette discussion(compatibilite ascendante) il n'entre tout simplement pas en compte.
                                                  • [^] # Re: Bonne nouvelle

                                                    Posté par  . Évalué à 3.

                                                    > Il y a la realite (il le fait tres bien, avec quelques problemes de temps en temps quand meme, il y a des bugs chez tout le monde), et le mythe repandu
                                                    > chez nos amis linuxiens qui ont tendance a ne pas comprendre comment un soft fonctionne et tout mettre sur le dos de MS(hint: le rendu depend de
                                                    > l'imprimante notamment)

                                                    Hmm quand tu ouvres simplement un document et que *sur ton écran* tes titres partent en cacahuète c'est un problème d'imprimante ?

                                                    > Elle est bonne celle-la...
                                                    >
                                                    > Latex 2 est sorti en 1994, Latex 3 ? Toujours pas sorti...

                                                    LaTeX ce n'est pas que le langage, tu as aussi tous les packages kivonbiens tout autour, et ce n'est pas parce que le numéro de version n'augmente pas que
                                                    des nouveaux packages n'arrivent pas.

                                                    Et je serais vraiment supris de voir MsWord20XX ouvrir un document écrit avec le MsWord de 1983.
                                                    • [^] # Re: Bonne nouvelle

                                                      Posté par  . Évalué à 2.

                                                      Hmm quand tu ouvres simplement un document et que *sur ton écran* tes titres partent en cacahuète c'est un problème d'imprimante ?

                                                      J'aimerais bien voir un cas de cela, t'as un document qui fait cela ?

                                                      LaTeX ce n'est pas que le langage, tu as aussi tous les packages kivonbiens tout autour, et ce n'est pas parce que le numéro de version n'augmente pas que
                                                      des nouveaux packages n'arrivent pas.


                                                      Un nouveau package par definition ne va pas affecter un document, vu que ce document ne l'utilise pas.
                                                      C'est un peu comme ajouter un plugin a Word, si le document n'utilises pas le plugin, aucune chance que ton document soit touche.
                                                      • [^] # Re: Bonne nouvelle

                                                        Posté par  . Évalué à 3.

                                                        > J'aimerais bien voir un cas de cela, t'as un document qui fait cela ?
                                                        Malheureusement non, mais je l'ai déjà vu.

                                                        > Un nouveau package par definition ne va pas affecter un document, vu que ce document ne l'utilise pas.
                                                        > C'est un peu comme ajouter un plugin a Word, si le document n'utilises pas le plugin, aucune chance que ton document soit touche.

                                                        Si j'ai fait allusion aux packages c'est parce que tu sous-entendais que LaTeX était au point mort avec LaTeX 2, alors que bien qu'il n'y ai
                                                        pas de nouveau ajout au langage à proprement parler, les packages sont là pour apporter de nouvelles fonctionnalités.
                                                  • [^] # Re: Bonne nouvelle

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

                                                    Latex 2 est sorti en 1994, Latex 3 ? Toujours pas sorti...

                                                    Et alors ?
                                                    • [^] # Re: Bonne nouvelle

                                                      Posté par  . Évalué à 3.


                                                      Bah rien, c'est juste qu'il voulait parler de la compatibilité entre logiciels, dont certains sortis il y a plus de 15ans.
                                                      J'ai parlé de LaTeX, et il m'a fait remarquer que LaTeX 2 n'est sorti qu'en 1994 (donc pas 15ans) et que LaTeX 3 est toujours dans les cartons s'tout.
                                                      Par contre LaTeX date de 1985, quant au langage TeX lui est bien plus vieux, il date de 1977.
                                                      • [^] # Re: Bonne nouvelle

                                                        Posté par  . Évalué à 5.

                                                        >> Latex 2 est sorti en 1994, Latex 3 ? Toujours pas sorti...
                                                        > Et alors ?

                                                        Je crois qu'il ne critique pas le fait que Latex n'évolue pas. Mais plutôt qu'il veut dire que puisqu'on utilise la même version de Latex depuis 1994, c'est normal de ne pas avoir de problème de compatibilité. (C'est juste une façon un peu ironique de le présenter)
                                                • [^] # Re: Bonne nouvelle

                                                  Posté par  . Évalué à 1.

                                                  Ouhais ca ca m'etonnerais pas mal vu que a l'epoque la meme version de microsoft office sur le meme systeme mais deux ordis differents etait pas capable de le faire sans compter que avant le microsoft ooxml (je n'ai pas retester depuis donc ca peut marcher ou pas) il etait impossible de garder un champ equation en tant que champ equation lors d'un echange de document entre pc et mac...

                                                  Mais bon comme il doit parler de la perfection non pas au masculin mais a la microsoft cela ne veut pas dire grand chose.
                                                  • [^] # Re: Bonne nouvelle

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

                                                    La question n'est pas de relever les "bugs" pour dire "MS c'est des naz niveaux compatibilité", la question est de regarder si dans les solutions alternatives c'est globalement mieux : prenons OpenOffice.org, l'alternative de référence. La comparaison est sans appel, niveau compatibilité y'en a un qui est bien meilleur que l'autre.
                                                    • [^] # Re: Bonne nouvelle

                                                      Posté par  . Évalué à 3.

                                                      Non la question est que pbpg dis des conneries point barre:

                                                      > Word 2010 t'ouvres toujours un fichier de Word d'il y a 15 ans avec une representation correcte si ce n'est parfaite.

                                                      C'est faux et archi faux, comme je l'ai dit la situation est peut etre differente avec du microsoft ooxml mais avec le format doc c'est un pur mensonge car ce n'est pas possible.
                                                      • [^] # Re: Bonne nouvelle

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

                                                        Arrête de t'exciter sur des conneries. Oui, un doc écrit avec word 95 aura du mal à être lu par Word 2010. Par contre un doc écrit avec Word 97 pourra être lu, est ceci de manière correct (ne veut pas dire "parfait"). On peut pas en dire de même de OpenOffice 3 avec un doc écrit avec OpenOffice 1.
                                                        Alors oui, la compatibilité ascendante n'est pas parfaite chez Microsoft, mais c'est clairement une volontée et un de leur atouts/inconvénients : ils traînent des boulets dans le code de leur logiciels, chose dont ne s'embarassent pas de nombreux logiciels libres.
                                                        • [^] # Re: Bonne nouvelle

                                                          Posté par  . Évalué à 0.

                                                          Alors oui, la compatibilité ascendante n'est pas parfaite chez Microsoft, mais c'est clairement une volontée et un de leur atouts/inconvénients : ils traînent des boulets dans le code de leur logiciels, chose dont ne s'embarassent pas de nombreux logiciels libres.

                                                          Deja qu'un document ODF est pas portable entre differentes suite implementant ODF, faut pas s'attendre a des miracles...

                                                          If you can find a host for me that has a friendly parrot, I will be very very glad. If you can find someone who has a friendly parrot I can visit with, that will be nice too.

                                      • [^] # Re: Bonne nouvelle

                                        Posté par  . Évalué à 3.


                                        Le résultat est le même : si demain Iguaza veut mettre Gtk# dans le standard .Net, il peut pas.


                                        Tu parles bien de Micel Iguaza, là ? :D
                                    • [^] # Re: Bonne nouvelle

                                      Posté par  . Évalué à 4.

                                      « Je ne pense pas que le comité qui s'occupe du C++ puisse s'assoir facilement sur GCC »
                                      Tu veux rire j'espère ? Des compilateurs C++ y'en a tout un paquet (icc, les compilos de PGI, ceux de Sun, etc.). GCC a mis un sacré bout de temps de passer de « GNU C Compiler » à « GNU Compiler Collection ». Peut-être qu'il y a des dév de GCC dans le comité de standardisation de C++, mais qu'ils soient derrière GCC, ou un autre compilateur n'est absolument pas pertinent. Pas plus pertinent qu'être dev pour un autre compilateur en tout cas.
                        • [^] # Re: Bonne nouvelle

                          Posté par  . Évalué à 3.

                          Encore une fois, tout ce qui est spécifique à Mono n'est pas contrôlé par Microsoft, mais bel et bien par la communauté. Et il y en a beaucoup, des bindings. Microsoft n'a rien à voir avec Webkit ou Gstreamer, non ?

                          Ça permet d'avoir d'un côté un langage pas si mauvais (ce que je lis à droite et à gauche) et de l'autre de bonnes librairies et une bonne intégration.

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

                    • [^] # Re: Bonne nouvelle

                      Posté par  . Évalué à 3.

                      Je dis peut-être une bêtise, mais il me semble que Gtk# fonctionne sous Windows/.Net. Du coup, ça en fait juste un framework pour faire du multiplateforme, avec ses avantages et ses inconvénients.

                      Avantages sur Python : (au fait : PyGTK ? tkinter ? PyQt ? wxPython ? Chacun a ses spécificités, ses avantages, ses inconvénients)
                      - Typage statique, vérifié à la compilation
                      - Pas la peine de distribuer un interpréteur python avec toutes ses libs si tu veux distribuer ton soft sous Windows.

                      Avantages sur Qt :
                      - Plus haut niveau (garbage collector, pas autant de soucis de nature historique comme QString vs std::string vs char*/QList vs std::vector vs liste chaînée à la main,…)

                      Si je ne te liste que des avantages, c’est pas pour te faire croire que Mono n’a que des avantages, hein, mais qu’il y en a, et qu’on ne peut pas réduire Mono à « un Qt contrôlé par Microsoft ».

                      Je crois que tu réduis beaucoup trop le choix d’un framework à des critères politiques. Tu cites par exemple Python comme si techniquement Python ou .Net c’était kif-kif et que le choix était purement et uniquement politique, alors que c’est faux, rien que la différence typage statique/dynamique est d’une importance primordiale pour beaucoup de projets.
    • [^] # Re: Bonne nouvelle

      Posté par  . Évalué à 10.

      Si Novell pouvait mourir, je n'en serais pas malheureux. Surtout si ça emporte mono et Suse dans la tombe au passage.

      Faut pas déconner, SUSE a apporté beaucoup au libre, notamment sur KDE. Tant que Mageia n'est pas au point, c'est la seule distribution qui y investit autant.
      • [^] # Re: Bonne nouvelle

        Posté par  . Évalué à 4.

        tu oublies pardus qui est la meilleure distrib KDE sur le marche.
        • [^] # Re: Bonne nouvelle

          Posté par  . Évalué à 7.

          Et aussi surement une des distribs avec le moins de packages disponibles
          • [^] # Re: Bonne nouvelle

            Posté par  . Évalué à 3.

            lorsque j'ai commence a tester il me manquait des packages, j'en ai parle sur le forum francais, deux jours plus tard ils etaient dispos.
    • [^] # Re: Bonne nouvelle

      Posté par  . Évalué à 0.

      Si ca ce trouve, Microsoft veut suivre le même chemin qu'Apple et donner à son prochain OS un noyau Unix avec une couche graphique maison...

      Vu sous cet angle, ca ferait sense.
      • [^] # Re: Bonne nouvelle

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

        Vu sous cet angle, ca ferait sense.
        Donc MS va bientôt racheter HTC.
      • [^] # Re: Bonne nouvelle

        Posté par  . Évalué à 2.

        Euh vu comment ils ont reussi a pervetir VMS, un super systeme, pour faire un truc comme Vista, j'aurai plutot peur.
        • [^] # Re: Bonne nouvelle

          Posté par  . Évalué à 5.

          Ils n'ont pas perverti VMS, ils ont embauché le mec qui a fait partie des créateurs de VMS, c'pas pareil quand même.
      • [^] # Re: Bonne nouvelle

        Posté par  . Évalué à 1.

        comment ça me ferait rire ça ! Depuis le temps que je pense que c'est le seul moyen de faire en sorte que Windows marche.
      • [^] # Re: Bonne nouvelle

        Posté par  . Évalué à 1.

        Je pense que unix est pas mal du tout, mais qu'aujourd'hui, si c'est pour repartir de zéro, autant construire quelque chose de neuf, avec des nouveaux concepts.

        Un système avec des fonctionnalités orienté objet par exemple, ça pourrais à être pas mal.

        Envoyé depuis mon lapin.

        • [^] # Re: Bonne nouvelle

          Posté par  . Évalué à 2.

          Je ne crois pas que Plan 9 implémente le concept objet, mais son idée de départ était justement de reprendre tous les défauts d'Unix. Peut-être une bonne base pour un nouveau système ?

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

        • [^] # Re: Bonne nouvelle

          Posté par  . Évalué à 2.

          Je pense que unix est pas mal du tout, mais qu'aujourd'hui, si c'est pour repartir de zéro, autant construire quelque chose de neuf, avec des nouveaux concepts.

          Un système avec des fonctionnalités orienté objet par exemple, ça pourrais à être pas mal.


          Hurd ?
      • [^] # Re: Bonne nouvelle

        Posté par  . Évalué à 2.

        Et ils voudraient faire ca pour quelle raison ? Ils se sont leves un matin en se disant que ca serait marrant ?
        • [^] # Re: Bonne nouvelle

          Posté par  . Évalué à -1.

          En fait, je ne sors pas ca de mon chapeau.

          Il y a un an, j'avais lu un article d'un ingé de Microsoft sur leur blog, qui parlait justement de cette possibilité.
          Dommage que je n'ai pas conservé le lien...

          Mais sinon, comme il a été dit plus tôt sur le ton de la rigolade, ca pourrait effectivement permettre aux OS de Microsoft de repartir sur des bases Unix éprouvées et donc de bénéficier de toutes les qualités de ces systèmes. Et accessoirement d'avoir la possibilité de se débarrasser d'une partie des reproches qui leur sont fait sur le coté passoire de Windows.

          D'ailleurs, d'un point de vu professionnel, j'en serais vraiment enchanté, car pour l'instant, le support des platformes Windows est pour moi un enfer au quotidien.

          Sans vouloir troller... ^^
          • [^] # Re: Bonne nouvelle

            Posté par  . Évalué à -1.

            Moi je te paries une Ferrari qu'aucun ingenieur Microsoft sobre n'a jamais dit ca. Rien que pour une question de cout et compatibilite.

            Mais sinon, comme il a été dit plus tôt sur le ton de la rigolade, ca pourrait effectivement permettre aux OS de Microsoft de repartir sur des bases Unix éprouvées et donc de bénéficier de toutes les qualités de ces systèmes. Et accessoirement d'avoir la possibilité de se débarrasser d'une partie des reproches qui leur sont fait sur le coté passoire de Windows.

            a) L'archicture Unix et Windows est deja quasiment la meme
            b) Windows n'est en rien une passoire. Si on se fie aux chiffres en bugs, a ce que la communaute securite pense plutot que ce que pensens les fanboys linuxiens c'est clair et net
            c) Je vois toujours pas un seul truc qu'un Unix (= grace a l'architecture Unix, donc tout Unix) peut faire qu'un Windows ne peut pas faire
            • [^] # Re: Bonne nouvelle

              Posté par  . Évalué à 2.


              a) L'archicture Unix et Windows est deja quasiment la meme

              A quel sujet plus précisément? Je suis dans le brouillard là.
              • [^] # Re: Bonne nouvelle

                Posté par  . Évalué à 2.

                Type de kernel, systeme multi-utilisateur avec permissions, etc ...

                Il y a bien evidemment de grosses differences en terme d'implementation (type de scheduling, structures internes, systeme de drivers, etc...) mais pas forcement plus qu'entre un Linux et un AIX ou HP-UX ou autre.
            • [^] # Re: Bonne nouvelle

              Posté par  . Évalué à 2.

              c) Je vois toujours pas un seul truc qu'un Unix (= grace a l'architecture Unix, donc tout Unix) peut faire qu'un Windows ne peut pas faire

              On peut certainement faire les même choses sous windows et unix, ceci dit sous unix je trouve que tout est plus souple grace au contrôle DAC et au modèle tout fichier
            • [^] # Re: Bonne nouvelle

              Posté par  . Évalué à 3.

              > c) Je vois toujours pas un seul truc qu'un Unix (= grace a l'architecture Unix, donc tout Unix) peut faire qu'un Windows ne peut pas faire
              pipe() + fork() pour les IPC ? Les périphériques accessibles dans le système de fichier ? /proc et /sys ? Les liens durs ? Toute la configuration du système accessible dans le système de fichier et éditable par un éditeur de texte ?
              • [^] # Re: Bonne nouvelle

                Posté par  . Évalué à 0.

                Les périphériques accessibles dans le système de fichier ?

                Joli abstraction, sauf que dans la realite, ca fait longtemps que ca n'est plus le cas pour plein de peripheriques pour lesquels tu passes par une API differente (son, carte graphique). Du coup l'interet est tout relatif (voir contre-productif dans certains cas ou une API differente est necessaire pour que ca marche => son).

                /proc et /sys ?

                T'as la meme chose sous Windows, c'est juste que l'API est differente

                Les liens durs ?

                Euh???????

                Toute la configuration du système accessible dans le système de fichier et éditable par un éditeur de texte ?

                Idem, en theorie. En realite de nos jours, il faut aimer editer d'enormes blobs de XML (ou pire). Avec bien sur des emplacements differents suivant les distribs et des infos dispersees dans 2 ou 3 fichiers differents. Du coup tu passes soit par des utilitaires en ligne de commande ou par une UI et tu t'en tapes du systeme de stockage derriere.
                • [^] # Re: Bonne nouvelle

                  Posté par  . Évalué à 2.

                  /proc et /sys ?

                  T'as la meme chose sous Windows, c'est juste que l'API est differente


                  Mais là est bien tout la différence.
                  Toute la beauté d'unix vient de ce coté tout fichier, ce qui rend le système souple, facilement adaptable et simple à administrer
                  • [^] # Re: Bonne nouvelle

                    Posté par  . Évalué à 2.

                    Desole, mais je vois pas en quoi cela le rend plus facilement adaptable et simple a administrer.
                  • [^] # Re: Bonne nouvelle

                    Posté par  . Évalué à 1.

                    Toute la beauté d'unix vient de ce coté tout fichier

                    Et a chaque fois on a droit a la meme chose!

                    Avec un compte ouvert en 99, tu dois pourtant savoir qu'il faut triturer un peu la verite pour arriver a dire que tout est fichier sous Unix...

                    Tiens, un peu de lecture:
                    http://lwn.net/Articles/411845/

                    Et la suite pour ceux que ca interesse:
                    http://lwn.net/Articles/412131/
                    http://lwn.net/Articles/414618/
                    http://lwn.net/Articles/416494/ (seulement pour les abonnes pour l'instant)
                    • [^] # Re: Bonne nouvelle

                      Posté par  . Évalué à 2.

                      J'ai lu que le premier (l'heure tout ça). Mais je vois pas où est le problème.
                      Dire que tout est fichier est évidemment un raccourci et une généralité, néanmoins cela représente bien l'utilisation que l'on a du système.

                      Avec un compte ouvert en 99

                      putain t'es salaud là, tu me files un coup de vieux.
                • [^] # Re: Bonne nouvelle

                  Posté par  . Évalué à 3.

                  > son
                  ls /dev/snd

                  > T'as la meme chose sous Windows, c'est juste que l'API est differente
                  /proc et /sys ne sont pas une API mais des fichiers, c’est bien ça qui le rend unique.
                  Je peux y accéder avec les outils standard de mon système (find & grep pour trouver rapidement, tar pour envoyer ma config à quelqu’un qui me dépanne) sans avoir à aller chercher le 5ème agrument de GetDevicePropertyW sur MSDNAA.

                  > Idem, en theorie. En realite de nos jours, il faut aimer editer d'enormes blobs de XML (ou pire).
                  Dans ton petit monde Ubuntu/Gnome/KDE seulement. Sur mon PC et mon serveur, tout est configuré à coups de vim.
                  • [^] # Re: Bonne nouvelle

                    Posté par  . Évalué à 2.

                    Même pas pour KDE et toutes les appli. qui en font partie. Ça utilise une configuration [section] et clef = valeur tout ce qu’il y a de plus classique.

                    Voilà c’était juste pour apporter une petite précision à ton commentaire (parce que de toute façon le commentaire parent est soit : un gros troll, soit quelqu’un qui n’a jamais réellement utilisé Linux car ce n’est pas possible d’en avoir une telle méconnaissance autrement).
                  • [^] # Re: Bonne nouvelle

                    Posté par  . Évalué à 1.

                    Grande nouvelle, t'as pas besoin du 5eme argument de GetDevicePropertyW , t'utilises reg.exe query <ce que tu veux> et tu trouves

                    Ensuites quand tu veux changer une valeur, t'utilises reg.exe set <ce que tu veux>

                    etc...

                    Si tu veux envoyer ta config, t'as reg.exe export

                    Tu peux comparer avec reg.exe compare

                    etc...

                    Et bien evidemment tu peux scripter ca dans tous les sens, et c'est de base dans l'OS depuis des annees.
              • [^] # Re: Bonne nouvelle

                Posté par  . Évalué à 1.

                pipe() + fork() pour les IPC ?
                Mais qui te dit qu'on ne peut pas rediriger les I/O sous Windows ?

                Les périphériques accessibles dans le système de fichier ?

                Lesquels ? Les disques ? Cela se fait sous Windows. La carte graphique ? Aucun Unix ne le fait

                /proc et /sys ?

                Oui ca s'appelle la registry, je vois pas trop la difference, t'utilises powershell et tu y accedes comme si c'etait un disque avec des repertoires

                Les liens durs ?

                Ils existent dans NTFS depuis sa naissance et ils ont toujours ete accessible.

                Toute la configuration du système accessible dans le système de fichier et éditable par un éditeur de texte ?

                Vois pas trop en quoi cela fait partie de l'architecture, et en quoi etre accessible par un editeur de texte est mieux qu'etre accessible par un autre soft.
                • [^] # Re: Bonne nouvelle

                  Posté par  . Évalué à 3.

                  > Vois pas trop en quoi cela fait partie de l'architecture, et en quoi etre accessible par un editeur de texte est mieux qu'etre accessible par un autre
                  > soft.

                  Avoir toutes les config dans des fichiers c'est quand même génial.

                  1/ Pour avoir la même configuration sur plusieurs postes il suffit simplement de recopier le ou les fichiers de config.
                  2/ Tu peux garder toutes tes config grâces à un CVS genre git, ce qui te permet de revenir à une config antérieur, faire
                  des tests, les partager très simplement, ...
                  3/ Automatiser la configuration, et activer/désactiver certaines options avec un simple script shell
                  (genre sed 's/machin=enable/machin=disable/' -i pwet.conf ou encore echo "machin=enable" >> pwet.conf)

                  L'avantage, c'est très clairement de se passer d'une API qui sera différente pour chaque soft et garder l'interface la plus
                  universelle qui soit: le fichier texte.
                  • [^] # Re: Bonne nouvelle

                    Posté par  . Évalué à 0.

                    > Avoir toutes les config dans des fichiers c'est quand même génial.

                    et tu crois qu'ils la stockent ou la config windows et mac?
                    Partant de la, tes deux premiers points sont non pertinents. Bon, windows centralise tout, ca aide pas a assembler des bouts, c'est sur, mais c'est pas un probleme texte vs api dediee.

                    Ton 3 se fait trivialement sous macos avec defaults write/delete, et avec une semantique autrement plus forte que de manipuler aveuglement des bytes.
                    Genre ca permet de s'affranchir des 42 format de confs en cours dans le monde linux et des 25 paths possibles pour la conf.

                    Je connais pas windows, mais je doute qu'ils ne proposent pas une api systeme (donc identique pour chaque appli) pour manipuler la registry.

                    If you can find a host for me that has a friendly parrot, I will be very very glad. If you can find someone who has a friendly parrot I can visit with, that will be nice too.

                    • [^] # Re: Bonne nouvelle

                      Posté par  . Évalué à 2.

                      > et tu crois qu'ils la stockent ou la config windows et mac?
                      > Partant de la, tes deux premiers points sont non pertinents. Bon, windows centralise tout, ca aide pas a assembler des bouts, c'est sur, mais c'est pas
                      > un probleme texte vs api dediee.

                      Je ne faisais pas une critique de la gestion de config de windows ou macos hein, je ne sais pas comment ils marchent. J'indiquais simplement les avantages
                      des fichiers textes, par rapport à un accès par un soft. Si tu peux y accéder avec n'importe quel éditeur tu peux facilement le sauvegarder/manipuler/...
                      Par exemple, je trouve gconf horrible, je préfère un fichier de conf par logiciel.

                      > Ton 3 se fait trivialement sous macos avec defaults write/delete, et avec une semantique autrement plus forte que de manipuler aveuglement des bytes.
                      > Genre ca permet de s'affranchir des 42 format de confs en cours dans le monde linux et des 25 paths possibles pour la conf.
                      Généralement les fichiers de conf sont dans /etc ou dans ton home (~/), après si on veut configurer un soft il vaut mieux la doc aussi...

                      Je ne sais pas quel est le format de confs de macos, mais tous les softs n'ont pas les mêmes besoins.
                      Entre configurer fetchmail ou procmail et apache ou postfix, bah c'est pas pareil.
                      Après il existe différents langage de script pour faire des choses un peu plus puissantes, comme lua.

                      J'aimerais aussi beaucoup que Guile, un dérivé de scheme, se développe d'avantage, et soit plus utilisé comme langage de configuration avancée.

                      > Je connais pas windows, mais je doute qu'ils ne proposent pas une api systeme (donc identique pour chaque appli) pour manipuler la registry.

                      Comme précédement. Le problème que je vois à l'API identique, c'est qu'elle n'est pas adaptée à chaque logiciel.
                      C'est chaque logiciel qui doit s'adapter à l'API. Il y a donc un manque de souplesse et de liberté.
                      • [^] # Re: Bonne nouvelle

                        Posté par  . Évalué à 2.

                        C'est les fichiers Plists sous Mac os x http://en.wikipedia.org/wiki/Plist
                        En gros, c'est des fichiers XML (exempl: http://pastebin.com/RW8aMQut )
                        En ligne de commande tu as la commande defaults qui:
                        Defaults allows users to read, write, and delete Mac OS X user defaults from a command-line shell. Mac OS X applications and other programs use the defaults system to record user preferences and other information that must be maintained when the applications aren't running (such as default font for new documents, or the position of an Info panel).
                        http://www.manpagez.com/man/1/defaults/

                        Comme précédement. Le problème que je vois à l'API identique, c'est qu'elle n'est pas adaptée à chaque logiciel.
                        Pourquoi? Si le format de stockage est suffisamment souple (genre une paire clef/valeur) le logiciel a juste besoins de pouvoir lire/écrire/modifier ces pairs.

                        Depending on the time of day, the French go either way.

                        • [^] # Re: Bonne nouvelle

                          Posté par  . Évalué à 1.

                          Pas forcement du xml, il me semble que le defaut c'est du binaire. Tu peux choisir en fait, c'est toi qui voit ce qui te convient le mieux, de memoire t'as le choix entre binaire, xml et properties.
                          D'ou l'avantage, une seule api pour acceder a la conf, et la serialization est laissee au systeme, dans le fond on s'en tampone, on veut juste recuperer une valeur.
                          Abstraction, separation of concerns, tout ca.

                          If you can find a host for me that has a friendly parrot, I will be very very glad. If you can find someone who has a friendly parrot I can visit with, that will be nice too.

                      • [^] # Re: Bonne nouvelle

                        Posté par  . Évalué à 0.

                        Généralement les fichiers de conf sont dans /etc ou dans ton home (~/), après si on veut configurer un soft il vaut mieux la doc aussi...
                        Comme tu dit generalement, a 2 endroits possibles. Potentiellement, ailleurs. Et ca change pour chaque distro, evidemment.
                        Le format du fichier passe son temps a changer aussi.
                        Ca peut etre du plain key/value, du [section] key/value, du xml, certains utilisent meme des csv (oui, ils sont tordus).
                        On sait pas trop quels encodage sont supportes, comment il faut echapper les chaines (ou s'il faut le faire tout court), ni quelles autres contraintes peuvent avoir les fichiers (taille de ligne, multiligne etc).
                        Et on a bien sur aucun typage, a savoir qu'une cle Date peut se faire affecter un booleen ou autre et tu le sauras qu'au runtime, potentiellement tard.

                        Apres, en pratique, ya une certaine tendance a bouger la conf vers du xml ce qui limite un peu ces problemes.

                        Face a l'avantage de pouvoir l'editeur de texte de mon choix, perso je prend le systeme robuste.

                        Comme précédement. Le problème que je vois à l'API identique, c'est qu'elle n'est pas adaptée à chaque logiciel.
                        C'est chaque logiciel qui doit s'adapter à l'API. Il y a donc un manque de souplesse et de liberté.

                        Ben une conf, c'est cle/valeur, j'aimerais bien avoir un seul exemple ou la registry windows ou les plist macos sont insuffisants.

                        If you can find a host for me that has a friendly parrot, I will be very very glad. If you can find someone who has a friendly parrot I can visit with, that will be nice too.

                • [^] # Re: Bonne nouvelle

                  Posté par  . Évalué à 4.

                  > Cela se fait sous Windows.
                  Je peux faire dd if=/sda1 | gzip > /media/external-disk sous Windows ?

                  > La carte graphique ? Aucun Unix ne le fait
                  Plan9 (oui, je suis légèrement de mauvaise foi ;))

                  > Oui ca s'appelle la registry, je vois pas trop la difference, t'utilises powershell et tu y accedes comme si c'etait un disque avec des repertoires
                  J’ai expliqué la différence : je peux l’utiliser avec perl, grep, awk, cut, tar, head/tail, paste, vim. La seule limite étant mon imagination.

                  > Vois pas trop en quoi cela fait partie de l'architecture
                  De l’architecture, philosophiquement en théorie, je sais pas, mais en pratique, je vois la différence entre /etc et la base de registres.

                  > et en quoi etre accessible par un editeur de texte est mieux qu'etre accessible par un autre soft.
                  Je suis obligé de me répéter ? Le choix du soft (regedit.exe n’est pas un modèle de clarté à mon goût). La capacité de combiner avec les outils standards.
                  Tu veux un exemple pratique ? J’ai dernièrement eu à regarder ce que faisait exactement l’installation d’un certain logiciel sur la configuration du système.
                  Sous unix, cp -r /etc /etc.old ; installation; diff -Nur /etc.old /etc
                  Avec regedit ? Je cherche toujours.
                  Tu vas me dire : « c’est simple, tu vas sur tel site de support de Microsoft, tu télécharges regedit-diff.exe, et ça marche, et en plus c’est graphique avec une interface kikoolol user-friendly à des années lumières de ce qui se fait sous Linux avec cette ligne de commande préhistorique. Seule ton incompétence sous Windows fait que tu sais pas faire ». Ben non, c’est justement mon argument : sous unix, je n’ai pas eu à découvrir et apprendre un nouvel outil. Je n’ai pas eu à faire un man etc-diff. L’outil standard marche sans me prendre la tête.
                  Et je peux faire pareil pour /proc et /sys. Pour windows, il me faudrait encore un n-ième outil, devices-diff.
                  • [^] # Re: Bonne nouvelle

                    Posté par  . Évalué à 2.

                    Je peux faire dd if=/sda1 | gzip > /media/external-disk sous Windows ?

                    Eh oui : http://support.microsoft.com/kb/q100027

                    J’ai expliqué la différence : je peux l’utiliser avec perl, grep, awk, cut, tar, head/tail, paste, vim. La seule limite étant mon imagination.

                    Ben oui, et avec powershell aussi

                    Je suis obligé de me répéter ? Le choix du soft (regedit.exe n’est pas un modèle de clarté à mon goût). La capacité de combiner avec les outils standards.
                    Tu veux un exemple pratique ? J’ai dernièrement eu à regarder ce que faisait exactement l’installation d’un certain logiciel sur la configuration du système.
                    Sous unix, cp -r /etc /etc.old ; installation; diff -Nur /etc.old /etc
                    Avec regedit ? Je cherche toujours.


                    Tu exportes la branche "software" de la registry, tu laisses le soft tourner, tu exportes la branche "software" de nouveau, et tu fais un diff, en utilisant exactement le meme soft que tu ferais pour un diff texte vu que l'export est textuel.

                    Et je peux faire pareil pour /proc et /sys. Pour windows, il me faudrait encore un n-ième outil, devices-diff.

                    Ben non, idem
                    • [^] # Re: Bonne nouvelle

                      Posté par  . Évalué à 2.

                      > Tu exportes la branche "software" de la registry, tu laisses le soft tourner, tu exportes la branche "software" de nouveau, et tu fais un diff, en utilisant exactement le meme soft que tu ferais pour un diff texte vu que l'export est textuel.
                      J’avais essayé et ça m’avait explosé à la gueule, je sais plus pourquoi. L’ordre des clés qui différait entre deux exports peut-être, mais c’est vieux (Windows 2000 je crois), donc je me rappelle pas bien.

                      > Ben oui, et avec powershell aussi
                      Powershell ne fait pas partie du système chez moi.
                      Mais oui, je reconnais qu’un Unix-like-over-Windows est appréciable. Ce qui prouve que l’approche Unix a fait des émules chez Microsoft aussi. Reste que c’est « récent » (relativement à l’histoire de Windows & Unix — 2005 il me semble), donc dire « je peux faire avec PowerShell ce que je peux faire avec Unix, donc l’architecture de Windows et d’Unix, c’est kif-kif »), c’est légèrement de mauvaise foi. Mais c’est pas grave, on est sur TrollFR. tl;dr: PowerShell est là pour prouver que :
                      - de base, on peut pas faire la même chose avec Unix et Windows
                      - l’approche Unix est suffisamment intéressante pour l’émuler au-dessus de l’approche Windows

                      Au fait, je peux faire vim sur une partie de la base de registre avec PowerShell ?
                      • [^] # Re: Bonne nouvelle

                        Posté par  . Évalué à 2.

                        Mais oui, je reconnais qu’un Unix-like-over-Windows est appréciable. Ce qui prouve que l’approche Unix a fait des émules chez Microsoft aussi. Reste que c’est « récent » (relativement à l’histoire de Windows & Unix — 2005 il me semble), donc dire « je peux faire avec PowerShell ce que je peux faire avec Unix, donc l’architecture de Windows et d’Unix, c’est kif-kif »), c’est légèrement de mauvaise foi.

                        Je crois surtout que tu melanges absence de couche d'abstraction avec absence de fonctionalite.

                        Depuis des lustres la registry a les memes APIs, ils n'ont pas change.
                        Ce qui a change avec powershell c'est l'ajout d'une couche qui donne l'aspect "disque" a la registry.

                        Depuis au moins XP t'as des outils en ligne de commande qui te permettent d'acceder a la registry de base dans le systeme et tu peux utiliser ces outils dans tes scripts ou pour faire un diff.

                        Au fait, je peux faire vim sur une partie de la base de registre avec PowerShell ?

                        Ca veut dire quoi 'faire vim' ?
                        • [^] # Re: Bonne nouvelle

                          Posté par  . Évalué à 1.

                          > Je crois surtout que tu melanges absence de couche d'abstraction avec absence de fonctionalite.
                          Non, c’est juste qu’à force de répondre point par point, on a fini par ne plus parler de la même chose : tu parles de fonctionnalité possible, moi de fonctionnalités accessibles « out of the box » par le design du système (sans nécessiter de couche d’abstraction derrière).

                          > Ca veut dire quoi 'faire vim' ?
                          Éditer avec vim. Je peux faire "vim /etc/fstab". Je peux faire vim (manière d’accéder au registre en PowerShell) ?
                          • [^] # Re: Bonne nouvelle

                            Posté par  . Évalué à 2.

                            Non, c’est juste qu’à force de répondre point par point, on a fini par ne plus parler de la même chose : tu parles de fonctionnalité possible, moi de fonctionnalités accessibles « out of the box » par le design du système (sans nécessiter de couche d’abstraction derrière).

                            Tu crois que le design du systeme dans Unix fait automatiquement que les devices et autres ont un file descriptor ? Non, ils ont tous une couche qui fait la translation.

                            Éditer avec vim. Je peux faire "vim /etc/fstab". Je peux faire vim (manière d’accéder au registre en PowerShell) ?

                            Tu m'expliques la logique ? Tu veux editer quoi dans la registry avec un editeur de texte ? Une entree qui est un chiffre ? Une entree qui est est une ligne de texte ?

                            Ta demande n'a aucun sens, un editeur de texte est absolument inutile pour la registry.
                          • [^] # Re: Bonne nouvelle

                            Posté par  . Évalué à -1.

                            Non, c’est juste qu’à force de répondre point par point, on a fini par ne plus parler de la même chose : tu parles de fonctionnalité possible, moi de fonctionnalités accessibles « out of the box » par le design du système (sans nécessiter de couche d’abstraction derrière).
                            Ca veut pas dire grand chose la.
                            Qu'il ya une couche d'abstraction ou pas, on s'en tamponne, tant qu'elle est fournie avec le systeme.
                            C'est le cas en l'occurence, ms fournit avec Windows les outils qu'il faut, Apple fait pareil avec MacOS.
                            A la limite, tant mieux qu'il ya ait une couche d'abstraction, ca evite de faire des conneries.

                            Le fait que tu puisses pas utiliser vi pour visualiser la registry est un non argument, sinon je vais te retorquer que je peux pas utiliser regedit pour visualiser la con' linux et que c'est un inconvenient.

                            Tu peux la scripter automagiquement, tu peux la bidouiller "en live" avec les outils fournis.
                            Par contre le fait que tu passes par une api dediee qui te garantit que tu vas pas foutre la chtouille dans ta conf, ca saybien.
                            Typiquement, probleme d'encodage de caracteres, fin de lignes, conversion type <-> texte ou toute autre contrainte de serialization.
                            Le fait que ca soit accessible via une api haut niveau evite par exemple de faire une boulette et de mettre un 0 la ou ca attends un false, ou inversement, plutot que de tout foutre en l'air a coup de sed.

                            Et tres honnetement, le fait de pas pouvoir utiliser sed et awk, je considere ca limite comme un avantage vu l'aride illisibilte de ces outils et leur cote casse gueule.
                            Cette approche etait probablement pleine de bon sens en 1978, mais l'eau a coule sous les ponts depuis.

                            Apres, on peut commencer a troller sur le cote centralise vs distribue, mais c'est un autre debat.

                            If you can find a host for me that has a friendly parrot, I will be very very glad. If you can find someone who has a friendly parrot I can visit with, that will be nice too.

                      • [^] # Re: Bonne nouvelle

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

                        donc dire « je peux faire avec PowerShell ce que je peux faire avec Unix, donc l’architecture de Windows et d’Unix, c’est kif-kif »), c’est légèrement de mauvaise foi.
                        Euh, la mauvaise foi c'est plutôt ne pas vouloir considérer la réalité et se référer au passer quand ça nous arrange. Si PowerShell était sorti y'a 2 mois, tu aurais une excuse, mais PowerShell est sorti y'a 4 ans, il est maintenant intégré par défaut dans les déclinaisons serveur et desktop de Windows : ça montre juste ta méconnaissance du sujet sur lequel tu trolls.

                        Au fait, je peux faire vim sur une partie de la base de registre avec PowerShell ?
                        PowerShell, c'est par définition la même chose que la ligne de commande sous Linux mais en plus puissant : les programmes ne communiquent pas avec des pipes de données quelconque mais communiquent avec des données structurées : bref la même chose avec des métas.
                        • [^] # Re: Bonne nouvelle

                          Posté par  . Évalué à 2.

                          > PowerShell, c'est par définition la même chose que la ligne de commande sous Linux mais en plus puissant
                          Ben non. PowerShell, c’est une couche d’abstraction, comme on l’a souligné.
                          vim, il travaille sur des fichiers, il utilise fopen & co.
                          Donc, je doute que taper "vim HKEY_CURRENT_USER\ma_clef" soit possible. D’ailleurs pBpG semble le confirmer puisque pour lui, « c’est complètement crétin de vouloir faire ça ».

                          Ergo : non, même avec PowerShell, tu ne peux pas faire tout ce que tu peux faire avec le shell Unix.

                          > ça montre juste ta méconnaissance du sujet sur lequel tu trolls.
                          Je ne nie pas. Juste que ce qui m’intéressait, c’était la comparaison entre le design « canonique » de Windows (tout est accessible par des handle avec les APIs qui vont bien) et de Unix (tout est accessible à l’aide de fichiers). Qu’on puisse faire des couches d’abstraction qui vont de l’un à l’autre, j’entends bien merci, j’avais pas besoin de troller pendant 3 jours pour le deviner. Que la couche d’abstraction « Unix-like » pour Windows soit maintenant fournie par défaut, je ne peux qu’applaudir des deux mains. Mais c’était pas ce qui m’intéressait.
                          • [^] # Re: Bonne nouvelle

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

                            Ben non. PowerShell, c’est une couche d’abstraction, comme on l’a souligné.
                            Comme Bash est une couche d'abstraction au dessus de certains API Posix. Je te parle des fonctionnalités spécifiques aux lignes de commandes, bref de ses possibilités en ligne de commande.

                            Donc, je doute que taper "vim HKEY_CURRENT_USER\ma_clef" soit possible.
                            Le problème c'est que vim ne sait pas discuter avec l'environnement powershell et les objets qui y circulent. vim est trop lié aux API Posix.
                            Mais si tu as un éditeur qui sait le faire, c'est une ligne de commande qui est envisageable.
            • [^] # Re: Bonne nouvelle

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

              L'archicture Unix et Windows est deja quasiment la meme

              Loulz
    • [^] # Re: Bonne nouvelle

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

      au contraire, suse est surement une des distributions les plus peaufiné, si elle est arrêté faudra voir tous les employés que novell avait sur le kernel, kde, gnome....

      www.solutions-norenda.com

  • # Droits sur unix

    Posté par  . Évalué à 4.

    C'est comme pour Mickey, je comprends pas qu'une antiquité de plus de 50 ans ne soit pas assimilée au patrimoine commun... bravo la loi US.
    Sinon, je vois pas comment un "mainmise sur unix" pas MS ne déclancherait pas tous les mécanismes antitrust...
    Et puis il y a une telle économie qui repose sur unix (serveurs, embarqué de tout poil : google, nokia...) que c'est impossible que tout s'effondre comme ça ?
    • [^] # Re: Droits sur unix

      Posté par  . Évalué à 4.

      Vu comment ils ont reussi a ne pas etre condamner alors qu'ils etaient en situation de monopole sur les PC il y a presque 10 ans je pense que l'on peut affirmer sans risque que la loi anti-trust ils en ont rien a carrer car ils ont deja "lobbyer" les bonnes personnes pour eviter tout probleme.
      • [^] # Re: Droits sur unix

        Posté par  . Évalué à 5.

        Etre en monopole n'est pas un crime, en abuser l'est.
        • [^] # Re: Droits sur unix

          Posté par  . Évalué à 2.

          Il me semble bien que la loi antitrust aux USA n'a pas ete fait pour punir un abus mais justement pour eviter les abus. D'ailleurs la defense de Microsoft cela fut l'existence de Linux et MacOS (a l'epoque microsoft ne pensait pas qu'ils allaient perdre plus de 20% du marche en faveur de ce derniere...)

          De plus que l'on prenne dans le sens que tu suggeres les abus microsoft sont tellement legions que cette boite aurait du etre eclate depuis bien longtemps.
          • [^] # Re: Droits sur unix

            Posté par  . Évalué à 2.

            Non, la loi US punit les _abus_ de monopole, pas etre un monopole en soi.

            Parce que des monopoles ici il y en a plein, notamment dans les telecoms, operateurs cable & internet, ...

            Quand aux abus, MS a ete condamne pour certains abus, et a perdu d'autres proces contre d'autres societes, ce qui montre qu'ils ne controlent pas la justice quoi que tu en dises.
            • [^] # Re: monopole

              Posté par  . Évalué à 2.

              Le Clayton Antitrust Act va un peu plus loin que les simples abus de monopole, mais à bien pour cible des situations de quasi-monopole .

              C'est sans doute l' ouverture des marchés , qui prévaut largement sur le marché intérieur, aux yeux des américains, qui a permis à Microsoft d'éviter une mise en accusation dans ce cadre, beaucoup plus que la loi elle même...
      • [^] # Re: Droits sur unix

        Posté par  . Évalué à -2.

        en fait, je pense qu'avant de continuer à baver des conneries, apprends à les écrire en français. parce que bon le mot communité n'existe pas en français. et puis il y a des règles d'accord dans cette langue. Toutes ces lacunes font craindre qu'un gamin de CM1 essaye de remplacer Schestowitz...
        c'est plutôt pathétique en fait.
    • [^] # Re: Droits sur unix

      Posté par  . Évalué à 3.

      C'est comme pour Mickey, je comprends pas qu'une antiquité de plus de 50 ans ne soit pas assimilée au patrimoine commun... bravo la loi US.

      Le développement d'Unix ne s'est pas arrêter il y a 50 ans mais a continué bien plus longtemps (et continue encore pour certaines versions).

      « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

      • [^] # Re: Droits sur unix

        Posté par  . Évalué à 2.

        Le développement d'Unix ne s'est pas arrêter il y a 50 ans

        D'autant plus qu'il n'a commencé qu'il y a 41 ans (1969).

        mais a continué bien plus longtemps (et continue encore pour certaines versions)

        L'éclatement d'Unix en ses dérivés s'est fait essentiellement au début des années 1980 (moins de 30 ans).
  • # M'en fous

    Posté par  . Évalué à 9.

    Perso je m'en tape, je suis sous "MultideskOS" alors vos histoire de pingouin, caméléon ou autre vache bossue...
  • # Aidons nos enfants

    Posté par  . Évalué à 3.

    Bonjour à tous,

    je voudrais ici livrer quelques remarques et commentaires, que ce soit pour le rachat (éventuel) de Novell ou autres.

    Etant utilisateur de Linux depuis 16 ans, je peux vous dire que non seulement ce système ne m'a jamais déçu, mais, en plus, j'en trouve une quiétude dans son utilisation quotidienne a titre privé, comme au boulot.

    Voici donc mes remarques :
    - tous le monde sait que le but de Microsoft n'est pas de construire des logiciels fiables et performant mais qui
    1) peuvent rapporter de l'argent à ces actionnaires et
    2) musèlent bien l'utilisateur ce qui arrange certains gouvernement.

    - dans les administrations par exemple, c'est une hérésie d'utiliser des logiciels Microsoft, tout d'abord pour le prix qu'ils coutent (je vous rappele que c'est notre pognon qui sert a cela), mais en plus du fait de la "non pérénité" de ces mêmes logiciels ils n'offrent qu'un panel limité de services possibles ... je vous le rappel : avec votre argent.
    Etant informaticien depuis de nombreuses années et ayant fortement militer contre les brevets logiciels, je puis vous dire que notre génération (d'informaticien) est une génération de sacrifiés ! On nous vend au plus offrant, soi disant pour des raisons "d'européenisation", mais il ne faut pas se leurer, ceux qui produisent pas d'argent en gagnent beaucoup (et ils sont peu nombreux) alors que ceux qui produisent de l'argent n'en gagne pas en conséquence de leur mérite (et ils sont majoritaire).

    - quand vous écouter les arguments de ventes des commerciaux, qui n'ont qu'un but , c'est vendre sans se soucier de la qualité de l'utilisateur, ils en arrivent très vite à des réponses du style "l'informatique linux c'est un monde d'anarchie", "60% des serveurs Linux et 100 % d'illètrés", ou le dernier en date, mon favoris (apès plusieur tentatives de sa part de faire passer les logiciels M$) "de toute façon, c'est le monopole qui compte".
    Je n'ai jamais entendu un commercial me parler "réellement" de son soft.

    Microsft rachete sans rien créer, renome sans rien inventer, musèle sans bruit. Nos gouvernement (encore une fois qui sont censé agir pour le bien du peuple et non des multinationales) ne se sont jamais opposé aux abus de position dominate (par Microsft entre autre). Demander comment se sont négocié les contracts logiciels pour la commission européenne il y a quelques années, ou pourquoi depuis 1995 les guichets des banques et autres vous répondent fréquement "désolé, nous ne pouvons vous répondre pour l'instant, notre réseau est en panne". Combien d'accord cadre ne sont pas signé entre les amdinistrations et Microsoft sans consultation ni même respect du cahier des charges et mise en concurence ? Ou plus simplement des "imposées" des administrateurs certifiés M$ dans des sociétés publiques en leurs faisant mirroiter des réductions sur le prix des licenses.

    Tous ces exemples sont réels, et je suis sûre que si on crée une liste de tout cela ... Internet en devient saturé.

    Soyons content d'utiliser Linux, c'est un beau système d'exploitation qui offre des possibilités quasi sans limite, mais avant tout : essayons de le faire pour nos enfants, c'est ceux ci qui auront la liberté (je veux dire "la vrai liberté") de travailler en informatique, nous avons été jeter comme des merdes par des politicards trop avide de se faire payer des vacances par ces grosses boites, sans comprendre où était le vrai bonheur des gens.

    Tout le monde sait où est le problème (Aung San Suu Kyi ne pourra jamais rien faire dans son pays, elle ne pactise pas avec les multinationales) mais il faut une volonté pour y arriver, et là ...
    • [^] # Re: Aidons nos enfants

      Posté par  . Évalué à 5.

      Tu es bien trop pessimiste !

      Dans ma boite on utilise tous Windows, c'est pas un choix, c'est juste que les applications clients ne tournent que sur Windows (bientôt Mac OS X pour Autocad, mais ça vaut pas mieux à mes yeux).

      Par contre on a un informaticien Linuxien, après des années d'un magnifique serveur Windows 2000, on est passé à un serveur Linux avec Zimbra pour le courriel et samba pour le partage de fichiers.

      Ca a quasiment rien coûté à la boite, ça s'est fait de manière transparente (le renouvellement du matériel aidant également), les performances au rendez-vous.

      Et que peut dire Microsoft ? Rien, ils ne sont pas compétitifs.
      Par contre le plus triste est qu'on me demande souvent (en tant que geek/développeur de service) des choses genre "Comment je peux trier les messages par objet dans Zimbre, tu sais, comme Outlook... ?" ou encore "Tu sais comment je peux attacher un fichier excel/word/insérer autre format propriétaire monopolistique ?"

      De même que malgré tous mes efforts la plupart des utilisateurs restent sur Internet Explorer, souvent la version 6 sur Windows XP...
      C'est assez décourageant de se sentir obligé d'expliquer ce qui cloche, surtout qu'on peut/veut pas te comprendre, qu'est ce que ça peut bien f***tre, c'est qu'une application.

      En plus les Linuxiens ne sont que des idéaliste illuminés, donc je parle souvent dans le vide.

      Par contre, même si Linux est un système "discret" comparé à Windows et Mac OS X (qui lui fait beaucoup parler de lui pour la place qui est la sienne), il n'empêche que l'on peut être assuré que sont existance n'est pas menacée, loin de là.
      Déjà le projet est plus actif que jamais, mais il a surtout un poid économique considérable, avec plein de grosses sociétés qui en dépendent à des niveaux variables et contribuent.

      Donc même avec toute la volontée de Microsoft ou autre boites dans le même genre (Oracle, Hewlett packard ?), on aura toujours la libertée d'utiliser nos ordinateurs, j'en suis persuadé.
      • [^] # Re: Aidons nos enfants

        Posté par  . Évalué à 3.

        Merci pour ta réponse,

        je n'ai pas dit que rien n'est fait, je dis que depuis le temps que les gens se plaignent du monopole Mircosoft et que si peu ne bouge ... on critique le prix, la lourdeur, les licenses ... mais quand on propose de jeter tout cela, j'ai une réponse assez classique "oui, mais on veut de la maintenance"
        Etant administrateur systeme (Unix/linux) et développant mes applications sous Linux (avec une compatibilité complète entre les sytèmes), je sais que je n'ai aucun problème, ni de plantage ni d'interopérabilité et pour avoir fait des développemant pour des administrations (jusqu'en asie), le seul problème est que jen'ai pas de maintenance à faire ni de mise à jour à facturer. Je suis retourné dans une boîte après 7 ans pour des formations et des gestionnaires sont venus me trouver pour me dire que mes scripts datant de 2000 tournaient toujours.
        De plus, ma remarque était aussi en regard du rachat d'une boite qui possède des technologies et des brevets par une boite qui ne pense qu'a se les appropriés pour l'entérer.

        Quant a ta "liberté" de pouvoir utiliser un PC, souviens toi de TCPA.

        Jettes un oeil sur http://kolab.org/

        Bien à toi
    • [^] # Re: Aidons nos enfants

      Posté par  . Évalué à -3.

      Moi je te suggeres de mettre un peu d'eau dans ton vin si tu veux etre pris au serieux.

      Les conneries genre MS n'a rien invente, MS veut faire des softs qui muselent ses utilisateurs, etc... c'est bon pour les fanboys linuxiens a qui ca fera plaisir, mais pour tout le reste de la planete qui a les yeux ouverts, ca te fait passer pour un extremiste decale de la realite.
      • [^] # Re: Aidons nos enfants

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

        tout le reste de la planete qui a les yeux ouverts
        Ça en fait du monde ! Un tas de gens clairvoyants autour de nous...
      • [^] # Re: Aidons nos enfants

        Posté par  . Évalué à 1.

        Merci pour ta réponse,

        je te range donc dans ma catégorie favorite :
        "de toute façon, c'est le monopole qui compte" (voir mon texte ci dessus)
  • # vmware

    Posté par  . Évalué à 2.

    Il manque une information.
    Vmware a participe au rachat de Novell.
    • [^] # Re: vmware

      Posté par  . Évalué à 1.

      Pas le temps de le caser dans la theorie du complot, ils etaient presses.

Suivre le flux des commentaires

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