Journal env TROLL=yes FRIDAY=yes echo Linux is defective by design

Posté par .
Tags : aucun
0
11
juil.
2008
Souvent, on dit que si M$ se fait beaucoup emmerder sur la vente liée, alors Linux aura des super parts de marché .
Personnellement, j'y crois pas, sauf si Linux utilise des méthodes monopolistes dont je ne douterais pas ("The Linux developers are selfish dickheads") .
On parle souvent de la mauvaise qualité de Windows (d'ailleurs quand va-t-il se faire dépasser par ReactOS ?), mais jamais des défauts de Linux . Je cache donc volontairement ses qualités .
1) Linux est dépassé .
Et depuis longtemps, puisque déjà en 1992 il était critiqué par Tanenbaum comme étant un gros noyau monolithique . Et de plus Linux n'a pas les couches de portabilité de NetBSD, ce qui fait que le code PCI doit en fait être réécrit à chaque pilote de carte PCI (IA32,IA64,SPARC,etc.), par exemple .
Référence : http://oreilly.com/catalog/opensources/book/appa.html
Et ça n'a pas changé pour la version 2.0, lorsque les modules sont apparus .
Le bon sens disait qu'il faudrait exécuter les modules dans l'espace utilisateur pour avoir une sécurité accrue en empêchant les pilotes de faire des conneries .
C'est surtout important dans le cas de pilotes expérimentaux ou de pilotes propriétaires, et ces 2 cas existent .
En faisant des modules s'exécutant en mode noyau, Linux 2.0 s'est tiré une balle dans le pied, sans aucun doute pour éviter de convertir les pilotes existants .
Résultat en 2008 : certains ont des affreux blobs de Atheros/ATI/Nvidia qui font ce qu'ils veulent de l'ordinateur .

2) Linux utilise abusivement le modèle du bazaar .
Je ne dis pas que le modèle du bazaar est mauvais, mais il manque une distribution de base officielle, une vraie distribution qui soit solide comme Debian ou Slackware . Ce serait comme la distribution officielle de FreeBSD, par exemple . Après, on peut faire comme DesktopBSD et faire des dérivés compatibles, mais AMHA il faut une distribution officielle de base pour que la majorité des distributions puissent être compatibles .
Debian et Slackware sont de bons candidats, mais il faut un avis des développeurs du noyau car sinon les distributions qui ambitionnent d'être la référence se multiplient et du coup aucune distribution de référence n'existe .

3) ALSA est merdique .
D'abord, un problème qui se remarque vite, dmix ne supporte pas l'émulation OSS alors que même FreeBSD arrive à mixer correctement pour des applications OSS .
Ensuite, sur la page http://4front-tech.com/hannublog/?p=5, petite traduction de morceaux que j'ai choisis .
Par rapport à OSS :
-Basé sur le standard UNIX/POSIX des fichiers dans /dev
-Une API simple qui rend le travail des programmeurs plus facile
-Uniquement dans le noyau
-Mixage virtuel transparent rendant possible pour un nombre arbitraire de programmes l'usage de la même carte son, enregistrement inclus .
Par rapport à ALSA :
-Mal documenté .
-Peu d'abstraction du matériel
-Conçu pour une latence 0 dont peu d'applications ont besoin, ce qui rend difficile l'utilisation normale .
-Nécessite des bibiliothèques redondantes augmentant la consommation mémoire . Cela augmente la charge pour les systèmes embarqués .
-Méthodes de transfert multiples .
-Certains pilotes utilisent des canaux entrelacés, d'autres pas .
-L'API est basée sur des callbacks qui nécessitent une compétence de haut niveau de la part des programmeurs . Les gotos sont considérés comme mauvais depuis des décennies . Les callbacks sont encore pires .
  • # boulet

    Posté par . Évalué à 8.

    1) (J'élude le reste, je n'ai pas les connaissances)
    En 92, Tanenbaum a dit que Linux c'est mal. C'était vraiment très intéressant.

    2) Tu ne fais que dire "une base de distribution saimieux", mais je ne vois pas pourquoi. Et "pour que la majorité des distributions puissent être compatibles", c'est un peu générique et plat...

    3) "[ALSA est] Conçu pour une latence 0", c'est clair que c'est vraiment un désavantage. OSS comme ALSA ont peu de fonctionnalités, dès qu'on veut quelque chose d'un peu puissant, il faut des bibliothèques.

    "Les callbacks sont encore pires ."
    boulet.
    • [^] # Re: boulet

      Posté par . Évalué à -5.

      >> Les callbacks sont encore pires .
      > boulet.

      ou pas.
    • [^] # Re: boulet

      Posté par . Évalué à -6.

      "2) Tu ne fais que dire "une base de distribution saimieux", mais je ne vois pas pourquoi. Et "pour que la majorité des distributions puissent être compatibles", c'est un peu générique et plat.."
      man FreeBSD
      man DesktopBSD
      man PC-BSD
      ""Les callbacks sont encore pires ."
      boulet."
      C'est une traduction .
      BOULET .
      • [^] # Re: boulet

        Posté par . Évalué à 3.

        "man FreeBSD"
        => "No manual entry for FreeBSD"
        T'as d'autres arguments plus explicites pour le neuneu que je suis ?

        "C'est une traduction"
        Tu le cites comme référence, et comme tu ne trouves rien à ajouter à ça, je suppose donc que tu es du même avis que lui.
  • # hourra !

    Posté par . Évalué à 9.

    On a trouvé deux défauts à linux, creusons encore mes frères et nous réussirons peut être à en trouver deux de plus !
    • [^] # Re: hourra !

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

      Il compile pas sous Windows ! o/
      • [^] # Re: hourra !

        Posté par . Évalué à 3.

        Heu...
        Et colinux, ils l'ont compilé comment ?
        Puis y'a gcc sous windows, je suppose qu'une cross compilation est possible aussi dans ce sens là...
        • [^] # Re: hourra !

          Posté par . Évalué à 1.

          Techniquement, peut-être, mais il faut savoir que si la cross-compilation Linux => Windows est bien maitrisée et (assez) bien balisée, l'inverse ne se fait pratiquement jamais. Pour avoir essayer personnellement ce genre de cross-compilation, je sais que les cross-compiler de GCC sont rarement maintenus et fonctionnent correctement encore plus rarement, même pour les fonctions les plus élémentaires.

          Bien sûr, GCC n'est pas en cause. Maintenir un cross-compiler est une chose ardu, demandant énormément de travail généralement peu gratifiant, et le niveau d'usabilité de ceux-ci est déjà un exploit en soit.
    • [^] # Re: hourra !

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

      3- pas de jeu
      4- pas de thunes
      5- pas de force commerciale
      6- Pas de support editeur (pas de photoshop, pas de Quark Express, pas de Catia)
      7- Pas de "finition" propre: le noyau est continuellement en developpement, ce qui laisse un avant goût d'inachevé
      • [^] # Re: hourra !

        Posté par . Évalué à 8.

        3 - des jeux dans un noyau ? concept assez intéressant je trouve ...
        4 - bah pas de tunes, ca servirait à quoi ?
        5 - une force communautaire, c'est encore meilleur
        6 - bah tu peux pas inclure photoshop, Quark Express ou Catia dans un noyau si tu es psychologiquement sain
        7 - l'informatique évolue, donc le noyau aussi, logique non ?
  • # Et?

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

    Tu as trouvé des défauts dans Linux, cool.
    Tu remontes le temps à 1992, il y a 16 ans... Je constate qu'en 16 ans, ton OS adoré a avancé de... rien du tout. En tous cas beaucoup moins que le truc "pourri" qu'est Linux.

    Si Linux a avancé 1000x plus que xBSD, c'est sans doute que Linux a certes des défauts, mais moins que ton OS adoré... Donc pourquoi ne pas parler des défaut de ton OS adoré? Genre l'incapacité chronique à avoir une seule distribution de référence (combien de branches xBSD pour combien de noyaux Linux officiels?), l'incapacité de faire des concessions pour avancer en attendant que tout le monde accepte le 100% libre (les drivers proprio, ça pue certes, mais au moins ça fait basculer des gens aux monde Linux...)

    Bref, du bruit pour pas grand chose de neuf.

    PS : je respecte autant les xBSD que Linux, c'est volontairement provocateur sur les xBSD juste pour une personne, désolé pour les autres (Je ne fais pas de jaloux, j'ai Windows encore à la maison, désolé :) )
    • [^] # Re: Et?

      Posté par . Évalué à 4.

      D'un autre côté, rester figé, c'est le meilleur moyen de ne pas se faire pourrir ...

      Je sors.
    • [^] # Re: Et?

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

      ton PS gâche tout
    • [^] # Re: Et?

      Posté par . Évalué à 7.

      J'utilise Linux et les BSD depuis 1994. Aucun n'est parfait (loin de là d'ailleurs, très loin de là), mais tu es de très très mauvaise foi dans tes arguments.

      Es-tu au courant que beaucoup de choses circulent entre les BSD et Linux ? Que les uns et les autres sont d'excellents systèmes ? Et surtout avec des buts différents.

      Tu prétends que Linux avance 1000 fois plus vite que les BSD. Il manque un lien pour étayer cette étonnante affirmation. Je n'ai pas encore vu Linux sur Amiga, sur Dreamcast, sur Sparc, sur VAX. Pourtant NetBSD fonctionne sur ces architectures. Je n'ai pas encore vu Linux sur les cartes embarquées traditionnelles dans les machines outils alors que NetBSD y réside depuis longtemps. Je n'ai pas vu non plus Linux étant aussi stable que NetBSD. Linux est très stable, mais mon expérience personnelle m'a montré que NetBSD l'est bien plus: je n'ai jamais vu son noyau planter. Ja-mais. Je gérais pourtant 14 machines allumées 24h sur 24 sous NetBSD.

      Tu prétends que les BSD n'ont pas de distribution de référence. Ah tient, il y a en 3 qui sont "très" principales. Le noyau Linux lui a un code source de référence, mais peu de distribution l'utilise tel quel, d'où beaucoup de "références" pour la configuration et les correctifs (une chez Debian, une chez Ubuntu, une chez Red-Hat, et chez Suze, une chez machin, ...).

      Tu prétends que les BSD sont dans l'incapacité de faire des concessions sur le libre. C'est un défaut ? Les chieurs d'OpenBSD par exemple arrivent parfois (souvent?) à faire mieux que les autres pour ouvrir les spécifications de certains matériels, tu trouves que c'est un défaut ? Les chieurs de NetBSD n'aiment pas du tout les blob entre autres parceque ça empêche de compiler sur des architectures étranges, tu trouves que c'est un défaut ?

      Ton PS indique que tu gesticules beaucoup alors que tu utilises Windows chez toi. Tu n'utilises donc pas Linux "en vrai à la maison".
      • [^] # Re: Et?

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

        Euh... Il y a un truc qui t'a sans doute échappé : j'ai volontaire grossi les traits, énormément grossi, pour une personne, et une seule, qui ne pense que BSD et "Linux ça pue".

        Sinon, je vais quand même réagir à certains propos :

        Ah tient, il y a en 3 qui sont "très" principales.

        3, c'est 2 de plus que Linux

        Le noyau Linux lui a un code source de référence, mais peu de distribution l'utilise tel quel, d'où beaucoup de "références" pour la configuration et les correctifs

        De mon point de vue, ça montre que Linux est 1000x plus utilisé que les xBSD : d'autres entreprises "jouent" avec le noyau Linux pour l'adapter à leurs besoins spécifiques, alors que pour les xBSD on installe et on met des trucs à coté. Je ne crois pas que les xBSD répondent aux millions de besoins spécifiques, juste que c'est moins développé et que ceux qui ont des besoins spécifiques prennent un truc qui leur convient mieux.

        je n'ai pas encore vu Linux sur Amiga, sur (...)

        Je n'ai pas encore vu de xBSD dans le top 500 des machines les plus puissantes, elles sont toutes spécifiques, ça en fait des architectures...
        Bref, tu donnes des exemples, il y en a d'autres pour Linux. Et je préfère un OS qui tourne sur des choses utiles que des proof of concept.

        Les chieurs de NetBSD n'aiment pas du tout les blob entre autres parceque ça empêche de compiler sur des architectures étranges, tu trouves que c'est un défaut ?

        Si ils refusent les BLOBS distribuables qui ne s'exécutent que sur le matériel précis, oui c'est un défaut, car ça n'empêche pas la chose de compiler sur x architectures différentes.

        Ton PS indique que tu gesticules beaucoup alors que tu utilises Windows chez toi. Tu n'utilises donc pas Linux "en vrai à la maison".

        Et alors, il faut être "utilisateur" pour critiquer? Impossible de discuter avec des utilisateurs de Linux ou de xBSD parce que je suis encore sous Windows à la maison? Désolé, j'ai horreur du racisme, et être anti-Windows est comme être raciste : je suis différent de toi, et alors? Ca ne m'empêche pas de pouvoir argumenter. Ta phrase est donc très mal venue, car elle n'a rien à faire dans le texte. Désolé, mais non, je ne pense pas que Windows c'est le mal absolu, vivre en communauté, c'est vivre tous ensemble, qu'on soit pro xBSD, Linux, Windows, ou Mac, dans que l'un respecte tous les autres, et je me répète, j'ai critiqué les xBSD juste pour remettre à leur place les anti-Linux pro-BSD, je ne suis pas un seul instant anti-BSD. Juste que les pro-BSD m'insupportent autant que les pro-Linux quand ceux-ci voient en leur OS fétiche le seul OS bon au monde.
        • [^] # Re: Et?

          Posté par . Évalué à 2.

          (les "3 qui sont très principales", c'est en fait une très principale par OS (FreeBSD est un noyau et une distribution en même temps, idem pour les 2 autres), ça va donc bien dans le sens qu'il disait)
      • [^] # Re: Et?

        Posté par . Évalué à 10.

        Je n'ai pas encore vu Linux sur Amiga, sur Dreamcast, sur Sparc, sur VAX. Pourtant NetBSD fonctionne sur ces architectures.
        Regarde mieux alors. En ce moment je suis même entrain de mouler sur linuxfr avec un système ayant un noyau Linux sur... un UltraSparc (supporte officiellement aussi Sparc).
        Pour tes autres exemples, il y fonctionne également. Il n'y a pas nécessairement de distribution proposant des binaires tout prêts, mais il fonctionne sur ces différentes machines/architectures.
        • [^] # Re: Et?

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

          Tu as tout à fait raison :
          Linux sur dreamcast : http://www.linuxdevices.com/articles/AT7466555948.html

          Ensuite : http://www.linux-m68k.org/
          Current releases of the m68k kernel are stable on the Amiga, Atari, many Apple Macintosh models, and several VMEbus single-board computers from BVM, Motorola and Tadpole. In addition, ports are underway (with varying levels of progress) to the HP 9000/300 series, the NeXT workstation (black hardware), the Q40 and Q60, and Sun 3 series workstations.

          Linux sur sparc ? : http://www.linux.com/base/ldp/howto/SPARC-HOWTO.html
          Linux sur VAX ? : http://linux-vax.sourceforge.net/

          On peut même voir sur la page NetBSD de wikipedia :
          NetBSD has been ported to a large number of 32- and 64-bit architectures [...] Although the Linux 2.6 kernel includes support for more processor architectures [...].
          Réference : http://en.wikipedia.org/wiki/NetBSD et http://www.kroah.com/log/linux/ols_2006_keynote.html
          • [^] # Re: Et?

            Posté par . Évalué à 3.

            [...] NetBSD supports more platforms than any single Linux distribution.

            Et oui c'est surtout ça qui est difficile, faire fonctionner l'OS complet pas juste faire booter le kernel (parfois en single-user seulement).

            C'est aussi pour ça que FreeBSD divise ses plate-formes supportées en tiers : http://www.freebsd.org/doc/en/articles/committers-guide/arch(...)

            Par exemple, il y a des développeurs qui bootent en multi-users sur du PowerPC ou du SPARC, mais ce ne sont pas pour autant des plate-formes Tier 1.
            • [^] # Re: Et?

              Posté par . Évalué à 4.

              Je pense qu'ils parlent ici de "plateforme" au sens d'une archi processeur + un ensemble de périphs spécifique à cette plateforme. On n'a pas l'habitude sur x86, mais par exemple le 68k ou le PPC sont des architectures, qui ont un paquets de plateforme (CHRP, NewWorld, ... pour le PPC). Et en général, je pense que linux tourne sur les plateformes "majoritaires". C'est vrai que celles dont un constructeur à sorti deux modèles de bécanes, ce n'est pas évident de porter un OS dessus vu la disponibilité du matos ...
              • [^] # Re: Et?

                Posté par . Évalué à 3.

                C'est vrai que celles dont un constructeur à sorti deux modèles de bécanes, ce n'est pas évident de porter un OS dessus vu la disponibilité du matos
                C'est clair que dans certains cas il est théoriquement possible de le faire, mais personne de compétent n'a le matériel sous la main :-) Il suffit de voir la liste des matériels désirés chez NetBSD pour s'appercevoir qu'on n'en connaît même pas le dizième.

                Cela dit, NetBSD à été porté sur x64 avant la disponibilité des processeurs, tout comme Linux, et probablement d'autres.
      • [^] # Re: Et?

        Posté par . Évalué à 2.

        "Je n'ai pas encore vu Linux sur Amiga, sur Dreamcast, sur Sparc, sur VAX."

        C'est bien dommage. Linux tourne sur toutes ses architectures. D'ailleurs, cela fait quelques temps déjà que Linux tourne sur plus de chose que netBSD.

        "La première sécurité est la liberté"

        • [^] # Re: Et?

          Posté par . Évalué à 2.

          Je suis au regret de t'informer que Linux ne tourne pas sur vax. Il y a un noyau qui est arrivé par le passé à aller jusqu'à monter un système de fichiers, mais il n'y a pas d'userland.
  • # Le son sous linux

    Posté par . Évalué à 3.

    Je profite pour demander, quelqu'un n'aurait pas un lien qui ferait le topo du son sous Linux actuellement ?

    À chaque fois que je tente de comprendre comment ça marche, je tombe soit sur des pages antédiluviennes (qui parlent d'OSS au présent, et d'ALSA au futur), ou alors des trolls bien poilus (qui parlent d'ALSA au présent, et d'OSS au futur, tel le lien du journal). Si à ça on rajoute les mixeurs qui changent selon le numéro de version distrib, j'en perds le peu de latin qui me restait.

    En pratique, j'ai un chipset audio pourri (un realtek), j'utilise en permanence le son sous Wine (et ce jusqu'à ce que ventrilo et foobar soient portés), j'ai envie de régler le son aussi bien de manière indépendante pour chaque application que de manière globale (pas d'enceintes).

    Y'a une solution viable (et pérenne) ? Ou je suis condamné à utiliser toutes les barres de volumes que je croise en espérant arriver à un compromis acceptable (ce que je fais actuellement).
    • [^] # Re: Le son sous linux

      Posté par . Évalué à 5.

      regarde du coté de pulseaudio, ce n'est pas parfait, mais c'est assez intéressant (surtout pour régler le son par application).
      • [^] # Re: Le son sous linux

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

        Je plussoie !
        J'ai longtemps galéré avec le son sous Linux, mais depuis que j'utilise pulseaudio, j'ai beaucoup moins de soucis. Je peux régler mon volume pour chaque application, le mixage de faire très bien. Et, étonnamment, c'est déjà supporté par pas mal d'applications, malgré sa jeunesse.
        • [^] # Re: Le son sous linux

          Posté par . Évalué à 6.

          Et, étonnamment, c'est déjà supporté par pas mal d'applications, malgré sa jeunesse.

          Disons que la sortie pulseaudio d'alsa aide pour beaucoup.
    • [^] # Re: Le son sous linux

      Posté par . Évalué à 2.

      Et bien OSSv4 permet très simplement et nativement de gérer le volume de chaque application audio indépendament. :)
      • [^] # Re: Le son sous linux

        Posté par . Évalué à 7.

        Ce qui est amusant dans ce journal, c'est cette petite contradiction (ok ce sont des propos rapportés, pour troller, alors allons y):

        -linux est critiqués pour être monolithique, avec les pilotes en espace noyau
        vs.
        -l'avantage d'ossv4 c'est d'être uniquement dans le noyau.

        On pourra remarquer que tout le post du developpeur d'oss pue la mauvaise fois, comme le souligne justement ce commentaire: http://4front-tech.com/hannublog/?p=5,#comment-422 .
      • [^] # Re: Le son sous linux

        Posté par . Évalué à 7.

        ouhais OSS4 c'est top moumoute parait il mais bon il y a 8 ou 10 ans lors du passage a Alsa OSS c'etait bien pourri. Pour faire fonctionner les cartes recentes il fallait acheter la version proprio alors que alsa (que je n'aime pas) permettait des choses impensables avec OSS et utilisable par tout le monde.

        J'aime bien les "troll" de ce style, l'historique est generalement bien oublies. De meme du pourquoi Linux et pas xBSD ce n'est pas a cause ou grace aux qualites intrinseque de linux mais a cause du proces Berkley/AT&T qui a bloque xBSD pendant des annees pour des risques legaux. BSD c'est tres bien, c'est tres beau, c'est un Unix mais bon sa non adoption ou plutot la domination de Linux dans les OS libres est une question historique et non technique!
  • # Bien essayé :)

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

    C'est une jolie tentative de troll, cela manque peut-être un peu de raffinement pour vraiment faire son effet.

    1) Désolé mais quand on lit [0], on a vraiment pas l'impression qu'il faut écrire la totalité du code PCI pour faire un driver. D'ailleurs ce serait la folie, au vu du nombre de driver PCI dans le Kernel, tu imagine la redondance énorme, la taille du code, les bogues potentiels et le volume que ça générerai.


    2) Effectivement on a pas de distribution référence, mais à quoi ça servirai concrètement ? tu as des standards, bon ou mauvais, comme la LSB. Fin bon, tu cite un fait sans dire ce que ça pourrais apporter selon toi. Ce qui serait intéressant c'est de savoir ce que cette distribution pourrait apporter au monde existant. Des standards, on en a déjà et des distributions utilisée pour être certifiée avec du matos pro aussi (genre SLES/RHEL), alors je vois pas à quoi ça servirai.

    3) J'y connais rien dans ce domaine (tout du moins, pour mes besoins, ALSA est très bien).

    [0] http://www.mjmwired.net/kernel/Documentation/pci.txt
    • [^] # Re: Bien essayé :)

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

      > Des standards, on en a déjà et des distributions utilisée pour être
      > certifiée avec du matos pro aussi (genre SLES/RHEL), alors je vois pas
      > à quoi ça servirai.

      C'est clair. On a en pratique trois standard de fait aujourd'hui : RHEL et SLES et à un degré moindre la debian qui si elle n'est pas officiellement supporté, à une base utilisateur qui doit obliger les constructeurs a en tenir un tant soit peu compte.

      Vouloir imposer un standard, c'est vouloir donner le monopole soit à Red-Hat, soit à Novell. Non merci.

      Je préfère l'approche LSB qui n'impose rien à l'utilisateur et qui ne l'installe que s'il en a l'envie.
  • # ...

    Posté par . Évalué à 5.

    Par rapport à ALSA :
    -Mal documenté .

    C'est pas faut...


    -Nécessite des bibiliothèques redondantes augmentant la consommation mémoire . Cela augmente la charge pour les systèmes embarqués .

    Pour la conso mémoire tu utilise la bibliothèque salsa. Pour la charge, la bibliothèque ne fait pas grand chose

    -Peu d'abstraction du matériel
    -Conçu pour une latence 0 dont peu d'applications ont besoin, ce qui rend difficile l'utilisation normale .
    -Méthodes de transfert multiples .
    -Certains pilotes utilisent des canaux entrelacés, d'autres pas .

    Et ben tu choisis celle qui te plait ou tu utilises un code qui te l'abstrait. Au point précédent tu étais à cheval sur la conso cpu et memoire et maintenant, tu voudrais qu'ALSA fasse des choses dans ton dos...

    -L'API est basée sur des callbacks qui nécessitent une compétence de haut niveau de la part des programmeurs . Les gotos sont considérés comme mauvais depuis des décennies . Les callbacks sont encore pires .

    Heu tu connais pas tres bien alsa. L'API callback d'alsa est malheureusement très limité...
    Sinon je te conseil de regardé comment fonctionne asio, portaudio, jack ... c'est que des callbacks...


    PS : la prochaine fois avant de troller documente toi un peu
  • # Comprends pas...

    Posté par . Évalué à 7.

    il manque une distribution de base officielle, une vraie distribution qui soit solide comme Debian ou Slackware

    Peux tu expliquer en quoi Debian n'existe pas ?
  • # Noyau Monolitique ?

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

    L'argument Monolitique vs microNoyau est un peu limité :
    http://fr.wikipedia.org/wiki/Noyau_de_syst%C3%A8me_d'exploit(...)

    Au premier abord, c'est très discutable aucun des deux n'est "meilleur" chacun a des énormes défauts...

    Ensuite pour reprendre ton argument : Le noyau Linux était déjà qualifié d’obsolète par Andrew Tanenbaum[6], dès sa création en 1991. Il ne croyait pas, à l’époque, pouvoir faire un noyau monolithique multiplate-forme et modulaire.

    Donc il s'est planté... fin de la discussion.

Suivre le flux des commentaires

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