Journal Microsoft réécrit Hurd ?

Posté par  .
Étiquettes : aucune
2
29
déc.
2008
Bonjour à tous.

n lisant cet article ( http://fr.news.yahoo.com/16/20081229/ttc-futur-de-microsoft-(...) ), j'ai eu l'impression que Microsoft utilisait le principe du micro-noyau et avait our but de réécrire Hurd (ou un truc vachement similaire). Quelqu'un a-t-il plus d'info sur ce sujet ( notamment PasBill PasGates s'il traine par ici ) ?

Je n'ai pas lu de spécification techniques précises cependant ce qui m'inquiète, c'est que Microsoft a déposé un brevet dessus .... A voir donc.

  • # hurd ?

    Posté par  . Évalué à 4.

    Pour le peu que j'en ai lu ça me fait plus penser à de la paravirtualisation qu'a hurd...

  • # Bof

    Posté par  . Évalué à 10.

    C'est bien gentil de rajouter des couches d'abstraction qui exécutent le code d'un interpréteur dans une VM qui va traduire les instructions dans un pseudo langage, mais ça finit par faire un peu beaucoup de couches à traverser.

    Moi j'attends toujours que Microsoft se décide à enfin jeter le legacy code et à écrire un vrai OS en C et assembleur, natif, et si au passage on pouvait se passer du BIOS qui se doit de tourner en mode réel 8086comem au temps des dinosaures, on aurait peut-être un temps de démarrage de Windows qui passe sous les 3 minutes. Ah, et que ça tourne sur un peu plus d'archis, genre Power PC, ARM, Mips, x86_64 et tout. Linux le fait bien, lui.

    Je parie qu'il y a encore des bouts de CP/M, de PC-DOS, d'EMM386 et de WIN.COM qui trainent dans Windows Seven...

    Encore un coup monté avec les constructeurs pour pousser les pauvres utilisateurs à acheter des cpu à 42 GHz et de la RAM au kilo.

    • [^] # Re: Bof

      Posté par  . Évalué à 10.

      C'est comme pour les autos d'aujourd'hui moins le consommateur en sait sur le fonctionnement interne ...

    • [^] # Re: Bof

      Posté par  . Évalué à 10.

      Les pauvres utilisateurs, ils aiment bien leur rétro-compatibilité.

      Enfin, on est pas vendredi.

    • [^] # Re: Bof

      Posté par  . Évalué à 5.

      Tu veux un OS en C et en assembleur qui fonctionne sur plusieurs archi ? Le 31 c'est après demain, pas la peine de vider les bouteilles avant l'heure !

      • [^] # Re: Bof

        Posté par  . Évalué à 6.

        Et Linux est écrit en quoi, à ton avis ? Et fonctionne sur quoi ?

        • [^] # Re: Bof

          Posté par  . Évalué à 4.

          Et bien justement Linux est écris en C mais certainement pas en assembleur (ou alors juste quelques petits bouts). L'assembleur a (entre autres) ce petit défaut de devoir être ré-écrit spécifiquement pour chaque architecture matérielle. Le truc même qu'on cherche à éviter pour la portabilité.

          • [^] # Re: Bof

            Posté par  . Évalué à 4.

            Pour le complément d'information...
            Linux dans les première version contenait pas mal de code en assembleur et un travail important a été de virer ce code pour l'ecrire en C de façon à ce que la maintenance (et le portage) d'une architecture soit la plus faible possible.

          • [^] # Re: Bof

            Posté par  . Évalué à 10.

            Linux est donc écrit en C et en assembleur, et c'est donc le meilleur moyen de faire quelque chose qui tourne partout.

            Il est évident que l'assembleur n'est pas portable, par contre le C a été conçu pour cela, à la base. D'autre part, on utilise majoritairement le C sous Unix parce que c'est historiquement une histoire d'amour (conçu par les mêmes personnes au même moment), mais rien n'empêche un usage beaucoup plus massif de l'assembleur au sein d'un projet, quoique les gens en pensent : d'abord parce que que les différentes architectures ciblées ne sont pas si nombreuses, et ensuite parce que les morceaux de code en assembleur peuvent quand même fonctionner sur toutes les machines utilisant le même microprocesseur si l'interface du code en question est écrite suffisamment proprement, indépendemment du système d'exploitation qu'il y a autour.

            GIMP, par exemple, gagnerait beaucoup à exploiter les extensions des différents processeurs pour faire son traitement d'image, quite à ne développer dans un premier temps que des modules accélérateurs pour les microprocesseurs les plus répandus, et retomber vers un code en C par défaut. Un filtre applicable sur un champ de bits développé pour x86 serait par exemple capable de fonctionner indépendamment sous Windows, sous Linux et sous tous les O.S. fonctionnant sur PC, ou sur une autre architecture utilisant le même CPU. C'est suffisant pour que ça devienne rentable.

            • [^] # Re: Bof

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

              Y'a pas besoin de coder en assembleur pour exploiter les instructions avancées des processeurs. Exemple en C# :
              http://tirania.org/blog/archive/2008/Nov-03.html

              • [^] # Re: Bof

                Posté par  . Évalué à 2.

                Évidement, mais il faut se fier au compilateur pour faire le travail. Les compilos modernes le font d'ailleurs de manière remarquable, mais ce n'est pas garanti à priori, et ce n'est pas propre à un langage.

                • [^] # Re: Bof

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

                  C'est un peu pour ça que Linux utilise plein de trucs spécifique à GCC. Ça permet d'utiliser des optimisation qu'on ne peut normalement que faire en assembleur depuis le C.

                  pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

            • [^] # Re: Bof

              Posté par  . Évalué à 8.

              Oui enfin, le C n'est pas portable hein. Tu as du C portable façon POSIX, du C portable façon ISO seulement, et surtout, surtout, quand il s'agit de coder un OS, même si tu essaies très fort, tu auras forcément des bouts de code totalement non-portables. Par exemple, les types en C ISO ne sont que des relations d'ordre, du type sizeof(char) <= sizeof(short) <= sizeof(int) <= sizeof(long), etc. D'où le besoin d'une norme POSIX qui propose des types fixes (uint32_t, etc) [1].

              Dès qu'on parle de programmation bas-niveau (telle que celle d'un OS), il ne faut pas voir le C comme autre chose qu'un « assembleur de haut niveau ».

              Concernant les bouts de code à « spécialiser » en fonction des architectures, je suis assez d'accord. Cela dit, ça fait quand même un grand nombre d'optimisations spécifiques. Alors si par exemple sur x86, on peut utiliser les intrinsics, le problème est que sur une autre plate-forme, le nom et la sémantique des instructions diffèrent, ce qui force à tout réécrire, et qui est tout de même assez pénible.

              Par exemple, sur PowerPC 32 bits, il existe 32 registres adressables, alors que sur archi amd64/intel64, on n'a que 16 registres (sans parler des x86 32 bits et de leurs 8 registres). Bref, dans le cas du ppc, on a plein de registres à disposition (RISC oblige), avec des instructions qui peuvent en tirer parti -- par exemple, il existe une instruction qui affecte les valeurs situées à partir d'une certaine adresse dans tous les registres, e.g. :
              r1 <- @tab[0]
              r2 <- @tab[1]
              ...
              r32 <- @tab[30]

              ... alors que sur x86, à cause de l'héritage CISC, on doit faire un peu différemment (en « vrai », il y a évidemment plein de registres sur un processeur x86, mais ils sont cachés, et on est obligé de faire confiance au matériel pour renommer les registres en interne de façon intelligente).

              Ce genre d'instruction n'existe pas pour le SSE d'Intel/AMD. En revanche, on y trouve des pxor (parallel XOR, qui permet d'effectuer des XOR sur 128 bits d'un coup), et autres choses plutôt sympa pour la crypto, par exemple.

              Sauf que voilà, du coup, l'algo sous-jacent à une certaine fonction (filtre pour traiter des images, ...) risque de différer pas mal d'une archi à l'autre. On se retrouve donc finalement avec une fonction qui a la même interface, indépendante de l'architecture (MIPS, PowerPC, x86, x86_64, ia64, etc), mais un fonctionnement interne très différent, avec des perfs elles aussi très différentes. Et surtout, il faut trouver des gens pour maintenir ce genre de code (un par archi, voire un par génération d'une même archi ...).

              Maintenir (et mettre à jour !) correctement ce genre de code est très délicat, car le moindre bug risque non-seulement de faire planter l'appli (cas « idéal »), mais surtout de donner un résultat erroné (et là, c'est déjà plus coton).

              Enfin, même si j'aime bien l'assembleur, je suis pour son éradication sauf cas exceptionnel. On a vraiment très rarement besoin d'accéder aux instructions assembleur. Déjà, en insérant de l'assembleur en-ligne dans un code C, on coupe toute velléité d'optimisation au compilateur (qui se « houla, il tripatouille autre chose que du c/c++/java/pascal/whatever, qu'il se débrouille puisqu'il est si malin »). Donc déjà, ça signifie faire une fonction à part, compilée dans un fichier objet. Ensuite, il faudrait déjà qu'il n'existe pas déjà une interface « C » (intrinsics pour SSE, instructions vectorielles pour profiter d'AltiVec sur ppc, etc) pour utiliser ces instructions SIMD. Généralement de toute manière, le nom des instructions est très proche de l'instruction assembleur correspondante. Par contre, au programmeur de vérifier l'alignement des données [2], sinon ça va planter grave, à lui de vérifier que l'opération qu'il veut effectuer est légale dans le cadre d'instructions vectorielles, etc.

              Il existe cependant quelques rares cas où il n'existe pas d'équivalent « C » à ce qu'on peut faire en assembleur. Par exemple, un de mes collègues, expert en cryptographie, râlait il n'y a pas si longtemps sur le fait qu'on ne pouvait pas récupérer des infos concernant les retenues ou les overflows (qu'on a dans le registre d'état, mais qui est totalement masqué dans les langages de 3è génération et plus).

              [1] Enfin si je ne me trompe pas, avec C99, ce genre de type rentre dans la norme du langage.
              [2] Tiens, encore un truc qui fait que le C n'est pas trop portable dans ce cas.

              • [^] # Re: Bof

                Posté par  . Évalué à 3.

                L'assembleur écrit avec amour à la main reste aujourd'hui incontournable si on veut l'efficacité maximale sur du code _très_ ciblé, tu as raison pour la cryptographie mais pour ma part je dirais qu'il y a des cas où du code vectoriel peut, encore aujourd'hui, être écrit plus efficacement à la main que par auto vectorisation ou intrinsics, même en l'absence de détails à la con mais qui font chier genre retenue.

                Sans compter que tous les backends ne se permettent pas forcement de s'émanciper de l'ABI lorsqu'elle n'est pas absolument nécessaire.

                Enfin je suis parfois obligé de me retenir (sans trop de mal, j'ai bien conscience que l'optimisation prématurée est la source de tous^W beaucoup de maux ;) pour éviter de pondre 5 lignes d'ASM qui résolveraient le problème d'une manière franche et efficace sur la cible, et où finalement je fais un truc moins bien en "C" (pour être plus précis j'appelle, avec une syntaxe C, une abstraction préexistante qui est typiquement codée en ASM et dont la sémantique est connue) histoire de faciliter la maintenance. Ex : bitops atomiques en kernel space où on peut sur certaines archi travailler sur plusieurs bits simultanément, chose qui n'est pas prévue dans l'abstraction haut niveau de linux.

                • [^] # Re: Bof

                  Posté par  . Évalué à 4.

                  L'asm est incontournable dans le cadre d'écriture de bibliothèques de fonctions, oui, car il s'agit d'avoir le code le plus « compact » et performant possible. Maintenant, je suis quand même assez assez sceptique sur son utilisation à outrance. Par exemple, l'utilisation des intrinsics est strictement équivalente à celle des instructions SSE sur x86 (tout au plus, si on utilise icc, ce dernier risque de dérouler plus d'instructions que ce qu'on a déjà fait à la main), et ça permet de garder du « C » partout dans le code, plutôt que d'avoir à insérer de l'asm, ou de devoir appeler une fonction rédigée uniquement en asm dans un fichier à part.

                  Pour les OS, évidemment, l'asm est nécessaire, mais si on peut l'éviter, il faut (ça semble « évident » dit comme ça, mais j'ai l'impression que beaucoup de gens préfèrent l'aspect bidouille à l'aspect « quand je reviens dessus plus tard, je sais ce que ça fait »).

              • [^] # Re: Bof

                Posté par  . Évalué à 4.

                Sur les registres : le e500 (un coeur d'ISA Power) contient aussi des registres de renommage, mais moins que de registres architecturaux (14 registres de renommage je crois) en fait ils optimisent le out of order, l'execution speculative et un mécanisme évite une latence entre deux instructions dépendantes exécutés en SU (les registres architecturaux étant écrit plus tard à la complétion in order).

                D'autre part je crois que stmw est transformé en de multiples opérations lors du décodage (on gagne certes en BP mémoire due au code mais bon on peut citer d'autres instrus sur d'autres archis qui font le café -- au final je ne crois pas que les binaires Power soient les plus denses).

                (j'ai survolé le e500 software optimisation guide il y a quelques jours :p )

            • [^] # Re: Bof

              Posté par  . Évalué à 2.

              Effectivement il peut être très intéressant d'avoir des routines en assembleur pour optimiser des parties critiques du code. Tant que ces routines ne représentent qu'une petite partie du code total, il est possible de prévoir des routines spécifiques à plusieurs architecture.

              Ce qui est souvent fait pour ces routines (exemple, les bibliothèques libGMP et OpenSSL) :
              - une implémentation C (lente mais qui marche partout)
              - des routines assembleur spécifiques

              À la compilation si du code assembleur adapté est présent il est utilisé. Sinon on se rabat sur la version C.

              Résultat: une exponentiation modulaire (en autres) 3 à 4 fois plus rapide qu'en pure C (sur un PC 8086, j'ai pas testé sur d'autres architectures).

    • [^] # Re: Bof

      Posté par  . Évalué à 7.

      De ce que j'ai compris de l'article, le brevet servirait justement a repartir sur un truc tout nouveau en virtualisant sans virtualiser (ou en hypervisant sans hyperviser ou ...) Windows Seven (ou antérieur) pour quand même garder la compatibilité. La couche d'abstraction ne serait là que pour faire tourner Windows.

      « 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: Bof

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

        Euh, à te lire on a l'impression qu'ils ont inventé un os qui fait marcher windows....Ca fait peur

        • [^] # Re: Bof

          Posté par  . Évalué à 5.

          De ce que j'ai compris, il ont créer un OS qui fonctionnera comme n'importe quel OS (enfin sans doute moins bien :-) ) mais qui permettra aussi de faire tourner Windows pour garder la compatibilité.

          « 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: Bof

            Posté par  . Évalué à 9.

            Un peu comme de Linux ! ^^

    • [^] # Re: Bof

      Posté par  . Évalué à 10.

      Y a pas mal de conneries qui se sont planqués dans ce post:
      1. Le kernel NT a été réécrit from scratch, donc Windows NT et ses successeurs (Windows 2k, XP, Vista, Seven) n'ont pas de code provenant des antiquités cités précédemment.
      Le legacy code, tu le trouves essentiellement dans des couches de compatibilité indépendantes de l'OS comme l'API Win32, les personnalités OS/2, Posix etc ...
      C'est un concept repris des travaux sur les micro-noyaux comme Mach et qui permet une certaine compatibilité avec des OS Legacy voire concurrent. Tu retrouves quasiment le même système sous OS X (Cocoa, Carbon, Classic, BSD, IOKit), dans le libre avec le micro-noyau temps-réel Xenomai et les personnalités (VxWorks, Posix, pSOS+, UiTron etc ...).
      C'est loin d'être con, et ça permet une transition en douceur à la fois pour les développeurs et les utilisateurs.
      2. Le kernel NT est écrit en C et C++ avec des vrais bouts d'assembleurs. Idem pour WinCE.
      Même aujourd'hui, on peut difficilement écrire un OS tournant sur du vrai matériel sans taper dans l'assembleur.
      3. Le kernel NT a été développé sur une plateforme non-x86 avant d'être porté sur x86 afin d'assurer sa portabilité. Windows NT a existé commercialement sur x86, MIPS, PowerPC, Alpha (Windows 2k a même été porté sur Alpha), Windows XP supportait encore l'Itanium, sans compter les ports qui n'ont jamais été commercialisés (SPARC, voire même les 68000 d'après certains).
      Windows NT (et ses successeurs) a été conçu pour être portable, même si les ports ont été abandonnés faute de succès commercials, il est très possible que Microsoft soit encore capable de les ressusciter comme l'a récemment fait Apple avec OS X.

      Je n'aime pas plus que toi Windows et Microsoft, mais pour être crédible, il faut un minimum d'honnêté dans une critique.

      • [^] # Re: Bof

        Posté par  . Évalué à 2.

        Pour la XBox360(http://fr.wikipedia.org/wiki/Xbox360#Sp.C3.A9cifications) c'est un CPU type Power, donc comme Microsoft n'a pas du réinventer leur OS(ça leur prend déjà du temps d'en écrire un...) c'est qu'il doit y avoirs de la portabilité dans l'aire...{+1 pour GeneralZod}

        Ensuite, c'est vrais que faire un système, sans virtualisation, etc...
        On va changer de CPU, pour que sa tourne on va passer a du QPU(Quantum Processing Unit)...

  • # Impossible

    Posté par  . Évalué à 10.

    Ce n'est pas possible de réécrire quelque chose qui n'a jamais été écrit.

    Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.

  • # Microsoft réécrit Hurd ?

    Posté par  . Évalué à 10.

    Ca serais bien... Au moins ils ne sortiraient plus rien.

    • [^] # Re: Microsoft réécrit Hurd ?

      Posté par  . Évalué à 3.

      pauvre hurd...

      pas encore sorti, qu'il y a déjà des brevets microsoft qui arrivent avant lui...

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

  • # Et les liens ?

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

    Alors pour cibler d'où vient l'info il suffit de remonter à la source :
    yahoo -> zdnet -> sdtimes.com

    Et pour les vrais informations il suffit de remonter tous simplement à la source :

    Singularity: Rethinking the Software Stack [http://research.microsoft.com/pubs/69431/osr2007_rethinkings(...)]
    "Advances in languages, compilers, and tools open the possibility of significantly improving software. For example, Singularity uses type-safe languages and an abstract instruction set to enable what we call Software Isolated Processes (SIPs). SIPs provide the strong isolation guarantees of OS processes (isolated object space, separate GCs, separate runtimes) without the overhead of hardware-enforced protection domains. In the current Singularity prototype SIPs are extremely cheap; they run in ring 0 in the kernel’s address space."

    SDTimes [http://www.sdtimes.com/MICROSOFT_S_PLANS_FOR_POST_WINDOWS_OS(...)]
    Midori is designed to run directly on native hardware (x86, x64 and ARM), be hosted on the Windows Hyper-V hypervisor, or even be hosted by a Windows process.

    Likewise for local concurrency, Midori will have a programming model, a platform stack and execution techniques that are intended to help developers write applications that can safely and efficiently use a greater number of hardware threads than is currently feasible. Elements in local parallelism interact through shared memory, which is the huge difference with distributed applications, said Microsoft distinguished engineer John Manferdelli, in a separate interview.

    Pour l'instant rien de neuf à l'horizon, sous Linux/Unix des sockets locales ou distants dans des programmes distribués ça se fait depuis un certains temps. Je pense que ce qui peut être nouveau c'est l'aspect montée en charge de l'application style Erlang.

    Cependant MS va encore ré-inventer ce qui existe mais va gagner avec leur pression commerciale. A voir notamment le papier (web) du SDTimes et ce que fait déjà Erlang.

    Pete Thinks [Way Too Much] [http://mikepetry.blogspot.com/2007/12/erlang-scalability-nex(...)]
    Erlang Concurrent Programming [http://erlang.org/course/concurrent_programming.html]

    • [^] # Re: Et les liens ?

      Posté par  . Évalué à 1.

      SIPs provide the strong isolation guarantees of OS processes (isolated object space, separate GCs, separate runtimes)
      ~> solaris containers, linux kernel namespaces & openvz
      Ou comment microsoft recupère aussi l'expression "On a rien sans rien"

    • [^] # Re: Et les liens ?

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

      Cependant MS va encore ré-inventer ce qui existe mais va gagner avec leur pression commerciale.
      Tu connais un autre OS qui utilises déjà une technique similaire aux SIPs de Singularity ?

      • [^] # Re: Et les liens ?

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

        En fait les SIPs existent déjà sous d'autres système (cf ci-dessus) mais pour MS cela ne suffit pas. Ils veulent intégrer ce mode de fonctionnement dans le langage de programmation afin de simplifier la gestion de ce mécanisme dans l'OS.

        Pour plus d'informations lit le pdf certes en anglais mais très intéressant pour qui s'intéresse aux mécanisme de protection et d'abstraction du matériel.

        le pdf : [http://research.microsoft.com/pubs/69431/osr2007_rethinkings(...)]

      • [^] # Re: Et les liens ?

        Posté par  . Évalué à 2.

        SharpOS + SharpOS AOT Compiler ?

        • [^] # Re: Et les liens ?

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

          Singularity existait alors même que SharpOS n'était qu'un sujet de discussion sur une mailing-list. Ensuite j'ai pas l'impression que SharpOS se base sur un concept similaire au SIP.

          • [^] # Re: Et les liens ?

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

            Après recherche, dans SharpOS ils ont rien de similaire pour l'instant, mais l'intention y est :
            "The SIP functionality that Singularity integrates is really one of the exciting parts of a managed operating system. Although we do not have code for processes yet (as we are still flushing out the AOT compiler, runtime, and corlib), we intend to use SIP (software isolated processes) as the first-class citizen process in SharpOS."

            • [^] # Re: Et les liens ?

              Posté par  . Évalué à 1.

              Ils y travaillent. Singularity est pour le moment un bon gros vapoware avec tout plein de fumée autour alors que SharpOS, on peut déjà se faire une idée du travail effectué. Il est d'ailleurs très probable que cet OS soit utilisable avec ces fonctionnalités plus tôt que le projet de Microsoft. À part quelques annonces et publications on n'a rien de concret à se mettre sous la dent.

  • # Etrange

    Posté par  . Évalué à 2.

    C'est étrange dans l'article donné en lien comment ils parlent de Singularity pour justifier un truc qui a l'air de n'avoir rien a voir. Pour rappel, la particularité principale de Singularity est d'être relativement prouvé. Par exemple avec Singylarity, tout les bouts de code sont assemblé au démarrage et il n'y a pas d'ajout de code en run-time. J'ai beaucoup de mal a voir cela dans un OS de bureau.

    Soit dit en passant Singularity est un excellent projet tres novateur, j'imagine qu'il doit être tres intéressant pour l'embarqué mais les auteurs disent bien qu'il n'a pas vocation a devenir le futur de windows.

    Quant à midori, en lisant l'article je me suis dit que ce qu'ils entendaient c'est par exemple de pouvoir passer de GNOME a KDE (remplacer par ce que vous voulez dans l'ordre que vous voullez). Je suis super impressionné, bravo Microsoft! Apres le shell vous inventer les interfaces graphiques intépendantes de l'OS.

    • [^] # Re: Etrange

      Posté par  . Évalué à 2.

      Moi ce que j'ai compris, le but c'est de pouvoir faire tourner Windows pour garder la compatibilité avec avant tout en ayant un tout nouveau système pour le futur, un peu comme si on faisait tourner un noyau 2.4 sur un 2.6 avec une vieille libc pour pouvoir faire tourner de vieille appli.

      « 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: Etrange

        Posté par  . Évalué à 6.

        ??????????
        Le prochain windows sera Hurd et utilisera Wine pour faire tourner les programmes ?
        ??????????

        • [^] # Re: Etrange

          Posté par  . Évalué à 2.

          J'ai pas l'impression que ce soit un truc comme Wine mais un truc qui fait tourner Windows comme il tourne sur un PC actuellement .

          « 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

  • # Midori ?

    Posté par  . Évalué à 2.

    D'après: http://www.pcinpact.com/actu/news/48129-singularity-midori-w(...)
    (ptin ils ne se sont pas foulés pour le titre ^_^ [ni pour l'image :O])
    le noyau deviendrait "Midori" .. ça ne serait pas le nom d'un navigateur libre ça ?

    • [^] # Re: Midori ?

      Posté par  . Évalué à 3.

      Si, si, mais ce n'est que le projet qui s'appelle comme ça, ce n'est aucun cas un nom commercial ... et puis il me semble qu'ils ont de toute façon le droit de l'utiliser vu que le logiciel est totalement différent (a moins que tu veuilles faire du browser un multiprise à OS..)

    • [^] # Re: Midori ?

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

      Bonjour

      Midori est un prénom féminin japonais.

      A bientôt
      Grégoire

      Pourquoi bloquer la publicité et les traqueurs : https://greboca.com/Pourquoi-bloquer-la-publicite-et-les-traqueurs.html

  • # Une distribution Linux ?

    Posté par  . Évalué à 4.

    C'est bizarre, mais l'article de PC Inpact sur le sujet me fait plutôt penser à une distribution Linux o_O

    En fait, Singularity serait le noyau avec un petit système de base, (genre µCLinux, basé sur busybox...) et qui ferait tourner des services. Pour l'interface, il suffit de lancer X et un gestionnaire de fenêtre, pour l'hyperviseur il suffit de lancer libvirt (avec du Xen ou du KVM derrière). Bref, on définit ce qui doit démarrer via un système de type RunLevel et on définit qui accède à quoi via SELinux...

    Quand on parle de rupture de compatibilité, il suffit de voir KDE 3 et 4 pour se dire que ce n'est pas spécifique à Windows (ok on n'est pas vendredi) ... Et si on veut du C#, on peut toujours coder avec Mono...

    Franchement, pour l'instant, la description du bouzin est trop légère pour en tirer des conclusions et imaginer un brevet basé sur l'innovation...

    Enfin ce que j'en dit...

    • [^] # Re: Une distribution Linux ?

      Posté par  . Évalué à 2.

      Moi ça me faisait plutôt penser à un micronoyau à la "hurd", notamment orsqu'il parlait de pouvoir désactiver les drivers sans arrêter la machine ... et quand ils parlaient de pouvoir faire tourner plusieurs versions de windows dessus (c'est ce que théoriquement les architectures à Micronoyau permettent de faire).

      Sinon pour les mavaises langues : dire que Hurd n'est pas sorti es assez faux : il existe un noyau Hurd qui tourne et permet déjà de faire beaucoup de choses .... Après effectivement, il est juste de dire qu'il n'est pas sorti en version stable.

      Cordialement.

      • [^] # Re: Une distribution Linux ?

        Posté par  . Évalué à 3.

        Tu peux aussi désactiver les drivers sans arrêter la machine avec un noyau Linux ; il faut juste qu'ils soient compilés en modules. Et si Windows n'est plus qu'une interface avec un ensemble d'outils systèmes, les environnements graphiques sous Linux font la même chose et on peut faire tourner plusieurs versions de ces environnements.

      • [^] # Re: Une distribution Linux ?

        Posté par  . Évalué à 2.

        Ce qui est decrit n'est pas relatif a Hurd ou aux micro-kernels, c'est plutot une nouvelle maniere d'avoir une HAL comme NT en a une.

        Sinon pour Midori, disons que c'est parti de Singularity, et que j'ai probablement pas le droit d'en dire bcp plus :+)

  • # Si seulement ...

    Posté par  . Évalué à 2.

    ... ça pouvait donner un coup de fouet (indirectement) à Hurd, ce serait pas plus mal.

  • # brevet de merde

    Posté par  . Évalué à 10.

    Ce brevet est l'illustration même du brevet "logiciel" de merde qui n'apporte rien, n'explique rien, est très mal écrit, couvre des idées abstraites générales au lieu de présenter des algorithmes les mettant en oeuvre, et pour combler le tout présente des choses banales déjà faites depuis 50 ans (ou des variations triviales de telles choses banales). Bref c'est un combo parfait dans l'horreur ; on n'en attendait pas moins de Microsoft -- et on a la confirmation que cette boite est toujours EVIL (pour ceux qui se seraient mis à en douter).

    Le pire c'est qu'on voudrait pouvoir le montrer aux décidorz pour illustrer à quel point les brevets sont devenus n'importe quoi et néfastes. Malheureusement ils risquent d'être aveuglement bluffés par la complexité à outrance (et crétine) de la rédaction qui peut laisser croire à quelqu'un qui ne l'étudie pas en détail ou qui n'est pas informaticien qu'il y a des choses intelligentes dedans.

Suivre le flux des commentaires

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