Nicolas Boulay a écrit 15824 commentaires

  • [^] # Re: rentrons dans le vif du sujet

    Posté par  (site web personnel) . En réponse au journal Linux un bloat, ah bon ?. Évalué à 2.

    Tu n'as pas du bosser beaucoup dans le dev de kernel linux toi :)

    Quand un gusse pète une api kernel, c'est à lui de réparer les dégâts jusqu'à ce que tout compile. Il sait ce qu'il change c'est infiniment plus rapide que de compter sur la personne qui ne comprendra pas forcément la subtilité du changement.


    Je vois pas le rapport avec la stabilité dans le temps. Windows arrive à offrir cette stabilité, pourquoi pas Linux ?


    Mais à quel prix ? Le prix de la perte de drivers à chaque version de windows, Linux n'a rien perdu !

    Les vendeurs de hardware se foutent rapidement de leur driver quand il n'est plus vendu.

    windows a aussi la force d'avoir 90% du marché, cela oblige les constructeurs à suivre. L'obligation n'est pas la même pour Linux !

    Je trouve que la solution actuelle est la moins couteuse pour avoir la meilleur qualité possible.

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

  • [^] # Re: rentrons dans le vif du sujet

    Posté par  (site web personnel) . En réponse au journal Linux un bloat, ah bon ?. Évalué à 2.


    Que je sache l'interface pour exécuter un programme est standardisé, je suis pas obligé d'inclure mon programme dans le repos du kernel il me semble. Ca m'empêche pas de faire du développement libre.


    Il est question de drivers pas de programme !


    Que je sache Gnome ou KDE ont des interfaces relativement stables et je peux maintenir mes logiciels dans mon coin sans les déposer sur les repos des environnements respectifs !


    Comparer des GUI et un noyau, c'est super gonflé. tu parles sans doute de ce qui se fait de plus facile à comparer à ce qu'il y a de plus dur.


    Pourquoi devrait-il absolument en être autrement pour les drivers dans l'environnement kernel ?


    Parce que cela n'a rien à voir ?

    Le libre prône il me semble l'indépendance à tous les niveaux, notamment à travers des standards.

    Quand cela a un sens, oui.


    Une API stable dans le temps irait beaucoup plus dans ce sens, mais ca fait chier l'équipe de dev du kernel, et les premiers à payer les pôts cassés sont les utilisateurs.


    Pour te donner un exemple, en ce moment, la mode est à la basse consommation. Cela implique que les drivers puissent déterminer quoi sauver en cas de perte de contexte et comment restaurer tout cela, quand le faire, quel contrainte de latence cela pose au système, quel genre et comment un évènement externe peuvent réveiller le système.

    Tu crois franchement qu'avec une API figé c'est faisable ?

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

  • [^] # Re: rentrons dans le vif du sujet

    Posté par  (site web personnel) . En réponse au journal Linux un bloat, ah bon ?. Évalué à 2.

    Certe et donc, qu'il ne veulent pas suivre un développement libre et qu'ils n'ont surement rien compris aux avantages pour eux.

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

  • [^] # Re: rentrons dans le vif du sujet

    Posté par  (site web personnel) . En réponse au journal Linux un bloat, ah bon ?. Évalué à 2.

    Dans ce cas tu auras des drivers tout pourris qui ne seraient jamais corrigé.

    Faire un drivers, ce n'est pas faire une petit appli KDE dans son coin. Il y a des interactions assez forte avec le reste du kernel !

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

  • [^] # Re: rentrons dans le vif du sujet

    Posté par  (site web personnel) . En réponse au journal Linux un bloat, ah bon ?. Évalué à 3.

    Non, c'est le boulot des distributions. Et si tu veux un truc à qualité garanti, tu utilises une distrib "stable".

    Et franchement quand tu vois la qualité moyenne des drivers offert pour le noyau linux, tu te dis que heureusement, ils sont repris par les codeurs kernel !

    mais non, Linus veut tout maîtrisé.

    Et cela marche mieux ! Regarde le bordel autour de X11 et des accélérations graphique, et de udev/hotplug.

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

  • [^] # Re: rentrons dans le vif du sujet

    Posté par  (site web personnel) . En réponse au journal Linux un bloat, ah bon ?. Évalué à 2.

    C'est toi qui le dit et ce n'est pas l'avis des codeurs noyau.

    Si il y a une regression, rien n'empèche d'utiliser le noyau précédent. Il sera corrigé ensuite. Personne n'a besoin d'avoir un nouveau kernel fonctionnel toutes les 6 semaines.

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

  • [^] # Re: rentrons dans le vif du sujet

    Posté par  (site web personnel) . En réponse au journal Linux un bloat, ah bon ?. Évalué à 2.

    Non justement, tu as plusieurs génération d'API a te trainer.

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

  • [^] # Re: L'utilisation récurrente de la vidéo d'Adolf Hitler pose question.

    Posté par  (site web personnel) . En réponse au journal Affaire Zataz suite. Évalué à 2.

    Si tu veux une version moins sympa pour hitler, ou il passe pour le colérique de service.

    http://www.youtube.com/watch?v=zwySDvEr7GY&hl=fr

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

  • [^] # Re: rentrons dans le vif du sujet

    Posté par  (site web personnel) . En réponse au journal Linux un bloat, ah bon ?. Évalué à 2.

    Les efforts de maintenance sont pour moi sur les drivers à chaque changement d'API. Des APIs qui changent moins souvent, ca demande moins de maintenance des drivers.

    il faut bien maintenir ton API qui est connecté qq part !

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

  • [^] # Re: rentrons dans le vif du sujet

    Posté par  (site web personnel) . En réponse au journal Linux un bloat, ah bon ?. Évalué à 2.

    les API stables ça marche.

    Va dire cela à ceux qui ont du matos qui n'est plus fonctionnelle sous Vista...

    Et non, doubler ou tripler l'effort de maintenance pour des bouts externes ne vaut pas le cout. Et je suis persuadé que 80% de la différence de qualité (plantage) entre windows et Linux, c'est justement cette gestion des drivers par le noyau. (sous linux, une bonne source de plantage, c'était le serveur X comme par magie en espace utilisateur, alors que c'est normalement une garantie de stabilité...)

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

  • [^] # Re: Rien de transcendant dirait-on

    Posté par  (site web personnel) . En réponse au journal Noop : encore un nouveau langage ou bien nouvelle génération de langage. Évalué à 2.

    Tu veux des "mémoires transactionnelles" en HW? j'ai des doutes sur ce qui est attendu exactement, mais j'ai l'impression que c'est encore un truc complexe que les softeux refilent au hardeux en croyant au Père noël.

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

  • [^] # Re: rentrons dans le vif du sujet

    Posté par  (site web personnel) . En réponse au journal Linux un bloat, ah bon ?. Évalué à 2.

    Disons que la FSF a décidé que le linker doit être stupide pour conserver des performances corrects.

    De plus, vu le peu d'info disponnibles, peu d'optimisation sont possible.

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

  • [^] # Re: rentrons dans le vif du sujet

    Posté par  (site web personnel) . En réponse au journal Linux un bloat, ah bon ?. Évalué à 2.

    Tu devrais lire le howto "stable api non sense" de la doc linux.

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

  • [^] # Re: rentrons dans le vif du sujet

    Posté par  (site web personnel) . En réponse au journal Linux un bloat, ah bon ?. Évalué à 2.

    Tu parles de téchno qui font ça au niveau du linker, cela n'existe pas au niveau GNU, justement pour des raisons de perfs.

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

  • [^] # Re: rentrons dans le vif du sujet

    Posté par  (site web personnel) . En réponse au journal Linux un bloat, ah bon ?. Évalué à 2.

    Lisaac est "bydesign" conçu pour mettre en contradiction les gains de perf avec la modularité du code.

    Pas du tout, c'est même complètement idiot comme argument. Lisaac favorise la découpe en horizontal et optimise en vertical.

    En gros, toute lib est compilé en global mais si tu veux faire des modules pour Linux, tu pourra à terme. Le coté "composant" de Lisaac n'existe pas encore, mais il pourra exister plus tard en ayant toujours la compilation global sur les libs. Le grain est bien plus gros que le fichier C.

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

  • [^] # Re: rentrons dans le vif du sujet (Compilation globale/séparée)

    Posté par  (site web personnel) . En réponse au journal Linux un bloat, ah bon ?. Évalué à 2.

    c'est pas suffisant le git ?

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

  • [^] # Re: rentrons dans le vif du sujet

    Posté par  (site web personnel) . En réponse au journal Linux un bloat, ah bon ?. Évalué à 2.

    sauf que tu doubles la base de code.

    Linux passe directement de la case je casse l'API à la case je corrige tous les drivers.

    Si l'API introduit une faille de sécurité tu la gardes ?

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

  • [^] # Re: rentrons dans le vif du sujet

    Posté par  (site web personnel) . En réponse au journal Linux un bloat, ah bon ?. Évalué à 3.

    Tu as un exemple ?

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

  • [^] # Re: rentrons dans le vif du sujet

    Posté par  (site web personnel) . En réponse au journal Linux un bloat, ah bon ?. Évalué à 3.

    La modularité dans le design du code est indépendant de la technologie que tu emplois derrière pour faire tourner le tout.

    Linux n'est pas un microkernel pourtant tout les sous systèmes sont clairement identifié en interne. Les drivers ont un système objet pour se déclarer et être utilisé par l'OS.

    Concernant le coté compile global de Lisaac, c'est une faiblesse qui est à relativiser. La compilation par fichier .c a été faite à cause de la faiblesse des machines de l'époque. Depuis la définition du C, les cpus ont gagné en vitesse, et la raison du saucissonnage du code n'a plus lieu d'être.

    On sait que Lisaac doit être capable de gérer des millions de lignes de code. Aujourd'hui, on sait que 50000 lignes se compilent en une dizaine de seconde sur un atom, mais derrière gcc rament franchement (qq minutes ?). Cela laisse de la marge.

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

  • [^] # Re: approche local vs. globale?v

    Posté par  (site web personnel) . En réponse au journal Linux un bloat, ah bon ?. Évalué à 5.

    Un peu comme ceux qui mettent la gui dans le noyau ?

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

  • [^] # Re: Tanenbaum avait-il raison ?

    Posté par  (site web personnel) . En réponse au journal Linux un bloat, ah bon ?. Évalué à 4.

    Certe mais je ne suis pas sûr que les applications utilisant le pilote soit dans un bon état.

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

  • [^] # Re: On ne parle pas de la meme chose...

    Posté par  (site web personnel) . En réponse au journal Linux un bloat, ah bon ?. Évalué à 3.

    C'était l'argument de BFS qui a besoin d'un ARM ou d'un Atom pour que cela soit vrai, vu que c'est déjà faux pour un core duo.

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

  • [^] # Re: Le troll

    Posté par  (site web personnel) . En réponse au journal Linux un bloat, ah bon ?. Évalué à 2.

    Et être hyper fort en HTML n'a pas trop d'intérêt pour faire un OS ou un compilo, bien au contraire.

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

  • [^] # Re: Train....

    Posté par  (site web personnel) . En réponse au journal SNCF : Antibes-Grenoble en 16h, c'est possible.. Évalué à 2.

    La cote d'azur est étiré le long du littoral. C'est peu dense dés que tu t'éloigne de la côte, un peu le contraire d'un centre ville. Comme beaucoup d'endroit tu te retrouves sur des routes à 90Km/h. Donc, un trajet de 15 minutes en voiture te prendrai plus d'une heure à vélo.

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

  • [^] # Re: voiture ?

    Posté par  (site web personnel) . En réponse au journal SNCF : Antibes-Grenoble en 16h, c'est possible.. Évalué à 2.

    ?

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