Cyril Chevrot a écrit 17 commentaires

  • [^] # Re: RMS est mort, vive Linus

    Posté par  . En réponse à la dépêche GNU/Linux est mort, vive GNU !. Évalué à 0.

    Bon j'avais déjà répondu mais le message n'a pas été posté :((

    Mon Dieu.. On en tient un beau

    Merci

    J'ai déjà répondu à ça, exactement le même titre

    Ce n'était exactement le même titre, les micro-noyaux, ca pue, c'est plus percutant que les micro-noyaux, c'est nul.

    qui n'a pas besoin d'être rebootée de façon régulière pour mise à jour du noyau

    Je ne sais pas si tu es au courant mais Linux est de plus en plus utilisé par des personnes qui ne savent même pas ce qu'est un noyau. Avancé cet argument pour démontrer que le HURD n'est pas seulement destiné aux développeurs c'est vraiment nul.


    De quelle couche d'abstraction parles-tu ? De quelle interface ? J'avoue ne pas comprendre à quoi tu fais référence.

    Avec un noyau monolithique, un appel système va directement tapé dans le noyau.
    Avec un micro-noyau, les appels systèmes sont implémentés au niveau des serveurs (1ère interface), les serveurs font appels aux services fournis par les taches d'entrées sorties (2 ème interface) et enfin les taches d'entrées sorties font appels au micro-noyau qui s'occupe de gérer les ressources et de passer les messages (3ème interface). Voila ce que j'appelle ajout de niveaux d'abstraction. (Enfin c'est ce qui se passe sous minix, je connais très mal HURD)


    Cependant, Mach n'est pas un modèle de vélocité, et faire un système performant basé sur ce micro-noyau n'est pas évident.

    Alors pourquoi l'utiliser s'il y a moyen de faire mieux ?

    <i>
    > Certes il y aura toujours des articles pour
    > dire que la perte de performance n'est pas si
    > terrible que ca, mais il y a toujours des
    > articles pour dire n'importe quoi.

    Argument frappant, je dois le dire.
    <i>

    Je confirme, et j'en suis fier ;)


    > Il suffit de se baser sur certaines mesures
    > précises pour prouver ce qu'on veut prouver.

    Soit plus précis. Que proposerais-tu de tester que les réalisateurs du benchmark n'ont pas testés ?

    Moi ce que je souhaiterais pour changer mon avis sur les micro-noyaux c'est que Hurd soit aussi rapide (au niveau de l'utilisation j'entends) que Linux et que ce soit une _priorité_.


    Pourquoi viens-tu parler du Hurd, alors ? Tu n'es pas devin, ni moi.

    Pipo Argument

    Prédiction de l'avenir => Test sur la compréhension du présent. Il est toujours bon d'essayer de prévenir l'avenir. Les personnes qui prédisent très mal l'avenir sont des personnes qui ont une mauvaise compréhension du présent et inversement. Ainsi pour savoir si l'on a une bonne compréhension du présent, il est bon de faire des prédictions, de les retenir et de voir quand le futur devient présent si l'on avait raison ou non. Et si l'on avait tort ils est bon de se poser des questions

    > N'en déplaise à Stallman et à son égo surmesurer.

    Encore un non-argument, trollesque, sans _aucun_ intérêt

    Si les trolls n'ont aucun intérêt, que fais-tu sur linuxfr ! Les trolls sont primordiales car ils permettent de se défouler ! Et se défouler c'est important, sinon comment expliquer le succès des doom-like, quake-like, des films violents et ... de linux (qui permet de se défouler sur microsoft)


    nous sommes pas là pour juger des personnes, que tu ne connais pas personellement

    Tu es le roi des arguments à la con à ce que je vois. Je ne connais pas personnellement les hommes politiques et cela ne m'empeche pas de les juger et ne m'empechera pas d'aller voter pour l'un d'eux aux prochaines élections. C'est meme mon devoir de citoyen.
  • [^] # Re: RMS est mort, vive Linus

    Posté par  . En réponse à la dépêche GNU/Linux est mort, vive GNU !. Évalué à 1.


    un micro-noyau c'est beaucoup moins lourd et coûteux qu'une JVM et ça apporte beaucoup plus AMHA.


    C'est vrai. Mais le problème de base reste le meme : en ajoutant des couches logiciels on s'éloigne du hard et on perd en performance.


    Si tu n'as pas compris que les différents entre RMS et Linus sont plus idéologiques qu'autre chose (RMS défendant le logiciel libre pour des raisons éthiques, Linus ne s'intéressant qu'au côté technique), et bien c'est dommage.

    Bien sur que je connais les différents idéologique entre le mouvement Open Source et la FSF. Bien sur que je sais que les 9 clauses de l'OSD sont plus pragmatique qu'idéologique.
    Maintenant les différents sont aussi technique. Linus n'aime pas emacs et Hurd. RMS aime les unoyaux, Linus ne les aime pas. Tu ne vas pas me dire qu'il ne s'agit pas de différent technique. D'une facon générale les différents entre les 2 sont avant tout basé sur une vision différente du monde : d'un coté il y a un pragmatique qui tire ces idées de l'expérience, de l'analyse du réel et de l'autre il y a un théoricien qui préfère les belles idées. Moi je me reconnais parfaitement dans la première vision du monde et pas du tout dans la deuxième. C'est mon droit maintenant tu es libres de penser différemment.
  • [^] # Re: RMS est mort, vive Linus

    Posté par  . En réponse à la dépêche GNU/Linux est mort, vive GNU !. Évalué à 2.


    >mais j'ai des copains qui ont utilisés Hurd et >Mac OS X et il m'ont dit que...

    J'ai appris a mes depends que se baser sur "ce que disent les copains" est *tres* mauvais. N'y voyez aucune agressivite de ma part, mais je ne pense pas que cet argument soit recevable.


    Je suis tout à fait d'accord. Personnellement tous mes jugements repose principalement sur _mon_ expérience. Je considère que l'expérience est au dessus de tout article, avis d'expert, avis de copain. Maintenant mieux vaut avoir l'information d'un copain que pas d'information du tout.


    Et surtout il ne me semble pas qu'il soit question que Hurd remplace Linux.

    Je n'ai rien contre le Hurd, ce qui m'énerve c'est le quasi mépris de Stallman envers Linux. Et le mépris de Linus envers le Hurd me direz vous ? Je vous l'accorde ca doit etre un truc de chef d'etre braqué. D'un autre coté faut bien qu'ils prennent des décisions. Et as nous de choisir notre camp.
  • [^] # Re: RMS est mort, vive Linus

    Posté par  . En réponse à la dépêche GNU/Linux est mort, vive GNU !. Évalué à -1.


    >>Les micros noyau, ca pue
    >Ca c'est de l'argumentation ! Chapeau !

    L'argumentation vient après. On t'a pas appris quand tu étais petit qu'il fallait commencer les paragraphes avec l'idée principale est l'argumenter après.


    Le développement Hurd a été (presque)
    complètement stoppé pendant des a
    nnées, c'est 1999 que Marcus l'a relancé.


    Justement ca montre bien que les micros noyaux rendent la conception plus difficile. Je ne pense pas que les développeurs HURD soient des brels, alors s'ils se sont découragés c'est bien que ca devait etre difficile.


    Et crois-moi, je ne dis pas ça pour être méchant, vu que ce genre d'arguments je les sortais il y a quelques mois avant que je ne me renseigne vraiment sur la question (j'ai un peu honte de moi maintenant mais bon... errare humanum est)

    Et oh, faut pas etre gentil comme ca, une réputation de trolleur ca ce travail ;)


    Le Hurd n'est pas optimisé pour l'instant. Les développeurs savent où sont les principales lacunes, savent comment y remédier, mais ce n'est pas la priorité

    La performance n'est pas une priorité, je crois réver. La performance devrait toujours etre une priorité.


    Tu as lu tout ce que Manuel Menal et moi (entre autres) avons dit sur les possibilités du Hurd ? Comment tu fais le translator FTP + Hostmux sous Linux ? Ou le générateur de fortune ? Ou le serveur Apache qui n'a jamais besoin des droits root pou binder le port 80 ? Ou le serveur FTP non anonyme qui n'est pas suidé root ? Et le fait qu'un bug dans un module fasse cracher la totalité du système ? Alors relis tout ce qu'on a dit sur cette page avant de sortir des phrases toutes faites comme ça.

    Ces fonctionnalités sont interessantes au niveau de la sécurité et du développement, mais bon je préfère un système ou l'on prend plus de risque et on l'on favorise avant tout les performances. De la même facon je préfère coder en C qu'en Java. Certes en java il y a un demi milliards de mécanismes pour prendre des précautions qui n'existe pas en C. Un code C a ainsi beaucoup plus de chance de planter à l'exécution qu'un code Java. Mais il est aussi beaucoup plus rapide (Je sais je n'aurais pas du prendre l'exemple de Java car la lenteur est principalement du à la vm, mais j'ai assez peu d'expérience avec le C++). Et les tests ca existent. La communauté Linux jouent sur la rapidité de développement et le feed back rapide des problèmes pour avoir un système sur et sécurisé. Je préfère cette approche que l'approche : on prend énormément de précaution et on optient une chute de performances.


    Quand à la personnalité de RMS, déjà je ne suis pas du tout d'accord avec ton jugement sur lui, et en plus je ne vois pas ce qu'il a à voir que le Hurd.

    Tu ne vois pas ce qu'il a avoir avec le Hurd !!!????!!?!. Le système GNU ca te dit qqchose ? Le Hurd est le noyau officiel du système, pas Linux. Et Stallman est bien verreux que Linux (ou Linus si tu préfère) lui ait piqué la chandelle : les messieurs tout le monde dans la rue connaissent moins stallman que Linus.
  • [^] # RMS est mort, vive Linus

    Posté par  . En réponse à la dépêche GNU/Linux est mort, vive GNU !. Évalué à -7.

    Les micros noyau, ca pue
    Hurd = 10 ans de développement et toujours pas pret
    Linux = Pret en moins d'1 an, fonctionnel en une poignée d'années
    Le but d'un micro-noyau c'est surtout pour les développeurs, possibilité de développer des modules en mode utilisateur, possibilité d'avoir des systèmes de fichier en tournant en mode utilisateur, ...
    Le problème c'est que si le passage de messages et la communication entre les processus rend le développement tellement compliqué qu'il multiplie le temps de développement par 10 je vois pas trop l'intéret pour les développeurs d'utiliser un m icro-noyau.
    De plus rajouter des interfaces et des couches d'abstraction c'est peut-etre beau sur le papier, mais à chaque fois ca entraine des chutes de performance terribles. Certes il y aura toujours des articles pour dire que la perte de performance n'est pas si terrible que ca, mais il y a toujours des articles pour dire n'importe quoi. Il suffit de se baser sur certaines mesures précises pour prouver ce qu'on veut prouver. Personnellement Java => ajout d'un couche d'abstraction (vm) => super long. De meme le fait que X est un processus dans l'espace utilisateur est certe une très bonne chose niveau conception (et je pense que pour le coup on a eu raison) cependant, je trouve qu'un des seules avantages de windows sur Linux est justement d'etre plus rapide au niveau de l'affichage (car le système de fenêtrage et justement dans le noyau). Et pour les micros noyaux, c'est encore le meme probleme, belle conception en apparence => chute de performance. Les belles idées sur le papier on a vu ce que ca a donné avec le communiste et apparemment on peut généraliser à pas mal de domaine la leçon. Le seul micro noyau que j'ai utilisé pour l'instant est minix (qui est nettement plus long que linux), mais j'ai des copains qui ont utilisés Hurd et Mac OS X et il m'ont dit que les performances étaient moins bonne que sur les OS monolithiques.
    De plus j'ai lu qq part que de toutes facon on n'avait de plus en plus de ressources processeurs et donc que les performances n'étaient pas si primordiales que ca. Cet argument est l'argument (récurrent) e plus débile de l'histroire de l'informatique. On aura _jamais_ trop de ressource et donc on se doit de concevoir les systèmes le plus efficacement possible.
    Quand à la modularité, avec Linux on a la modularité au niveau du source. De plus les modules ne constituent pas du rafistolage mais plutot le juste milieu.

    D'ou ma conclusion :

    Hurd ne remplacera _jamais_ Linux car si Hurd devait triompher Hurd aurait _déjà_triompher. N'en déplaise à Stallman et à son égo surmesurer.
  • [^] # Re: Retour vers le futur

    Posté par  . En réponse à la dépêche GNU/Linux est mort, vive GNU !. Évalué à 1.

    Linus déteste emacs (et Stallman et et les unoyaux (donc Hurd) comme tout le monde sait), donc ca m'étonnerait vraiment que le noyau de Linux se mettent à ressembler à Emacs. Le noyau officiel est très nettement conservateur et seule les fonctionnalités que Linus trouve vraiment importantes sont ajoutées, contrairement à la branche maintenu par Alan Cox.
  • [^] # Chemla raconte = je me l'a raconte

    Posté par  . En réponse à la dépêche Chemla raconte son experience. Évalué à 4.

    J'ai juste lu le début mais n'irais pas plus loin. Je déteste le style de ce livre. Je n'ai rien à priori contre les pamphlets, bien au contraire j'en suis meme friand. Le problème avec les pamphlets c'est que dans 95% des cas ils sont mauvais. Et celui là est particulièrement mauvais. Le style moi je sais tout mieux que tout le monde, je suis hyper fort et j'écrit parce-que j'ai plein de choses à vous apprendre m'énerve énormément. Au bout de la première ligne je me suis dit, c'est sur, il va nous parlé de ces histoires de piratage. Et ca n'a pas loupé. Personnellement je suis un grand fan des vrais hackers (au sens étymologique du terme), je suis le premier fan sur Terre de Linus, j'aime bien David Miller également mais par contre le milieu des hackers pirates puent graves. Dans ce milieu il y a des types biens mais très peu et des types qui se la jouent, et ca il y en a beaucoup trop. Qu'on s'intéresse au piratage parce que c'est intéressant c'est une chose, mais s'y intéresser parce-que ca fait petit génie de l'informatique c'est vraiment minable.
    Et Chemla fait sans aucun doute partie de la seconde catégorie.
  • [^] # Re: Autre mesure

    Posté par  . En réponse à la dépêche La France, pays de pirates???. Évalué à 3.

    guru = hacker + look and guru attitude
    Bref c'est rms ;)
  • [^] # Re: Autre mesure

    Posté par  . En réponse à la dépêche La France, pays de pirates???. Évalué à 10.

    Il serait bien de préciser aux responsables de cette étude que le mot hacker n'est étymologiquement lié à la piraterie inforamtique.
    Quelle est l'intérêt de rescencer des articles sur les optimisations de code lorsque l'on fait des études sur la piraterie informatique (je prend cet exemple en référence à l'article hack en C de nico dans Linux Mag).
    De même les hackers de kernel ne sont pas forcément de "vilains garcons". D'ailleurs Linus, dans sa bio, dit qu'il se définirait très certainement comme un hacker mais qu'il utilise ce mot avec précaution du fait de la tournure qu'il a pris.
    Personnellement je trouve dommage que les médias ait détourné le sens original de ce mot car je préfère qualifier rms, linus, alan cox, david miller, ... d'hackers plutot que d'informaticiens. En effet informaticien ne veut pas dire grand chose, il désigne aussi bien les génies que je viens de citer que les personnes alignant du html toute la journée ! C'est pour ca que le mot hacker dans sa signification originale est à mes yeux vraiment utile.
  • [^] # Re: Mon expérience perso...

    Posté par  . En réponse à la dépêche Systèmes de fichiers journalisé sur Linux. Évalué à 10.

    c'est pas temps réel mais débit garanti



    bah, si, justement. C'est bien ça le temps réel :

    Le principe du temps réel, c'est que l'on connait le temps exact que va mettre telle ou telle action. Donc c'est içi un exemple pratique : on est sur du débit dont on dispose pour enregistrer par exemple la vidéo...




    Tout ceci est exact mis à part que l'on ne connait pas réellement le temps exact d'une action mais plutot une _borne supérieure_ du temps d'exécution tache.

    Plus généralement on n'a à faire à un système ou à une application temps réelle lorsque l'on associe des contraintes temporelles aux taches et que le système (ou l'application) les respecte. Généralement ces contraintes temporelles s'expriment sous la forme de date limite d'exécution des taches à ne pas dépasser.



    Il est important de noter que, contrairement aux idées recues, temps réels ne signifie pas vitesse réelle. Ainsi une application de transmission vidéo qui assurerait un débit de 10 images par secondes ne serait pas une application en vitesse réelle mais serait tout de meme une application temps réelle.



    De plus si la définition du temps réel ne s'axe pas directement sur la garantie de certains débits, les applications garantissant certains débits sont des applications temps réels. Pour prendre l'exemple le plus classique de la transmission vidéo, si l'on veut garantir un débit de 25 images/s alors chaque tâche "affichage d'une image" à pour date limite d'exécution :

    date du début de l'application + nbr d'images ayant déjà été affichée * 40ms + 40 ms

    vi, mais temps réel c'est plutot associé a la gestion des processus, alors que la c'est plutot comment sont organisées les données sur le disque pour garantir le débit

    La encore, tu n'as pas tout à fait tort mais ca n'a rien de contradictoire avec la nécessisté de garantir des débits ou de facon générale de respecter les dates limites d'exécution. C'est meme directement lié. En fait dire que le temps réel est associé au gestionnaire de processus n'est pas très précis, il est plus précis de dire que l'ajout de contraintes temps réels à un système exige une modification de l'ordonnenceur (qui est la partie la plus importante du gestionnaire de processus). En effet quand plusieurs processus s'exécutent simultanément et que certains d'eux ont des dates limites d'exécution (deadline), c'est à l'ordonnanceur d'ordonnancer correctement les processus afin que les dates limites d'exécution soient respectées.



    Pour de plus amples informations sur le temps réel je vous conseille l'excellent site :

    http://www.real-time.org(...(...))

    créé par un chercheur E. Douglas Jensen, ayant fait ses études à Carnegie Mellon, ayant 30 ans d'expérience dans le domaine et ayant dirigé les spécifications temps réel de Java.
  • [^] # Re: Bel exploit

    Posté par  . En réponse à la dépêche Systèmes de fichiers journalisé sur Linux. Évalué à 2.

    > j'aurais pas pue le traduire, c'est trop technique.



    Les articles techniques sont généralement les plus simples à traduire. Les termes techniques restent les même d'une langue à l'autre et les autres termes sont des termes courant.

    Pour ma part je trouve qu'une relecture préalable aurait été une bonne chose !
  • [^] # Re: interet d'une IDE sous Linux

    Posté par  . En réponse à la dépêche C++ Builder sous Linux : bientôt du neuf !. Évalué à 1.

    Tu peux utiliser les makefile sous VC++, de la meme facon que tu peux utiliser gimp, emacs et une bonne partie des commandes Unix sous Windows.

    Certes tu peux programmer avec un style Unix sous Windows mais la n'était pas mon propos.

    Mon argumentation ci-dessus chercher avant tout à comparer le _style_ de programmation Unix au _syle_ de programmation Windows, rien de plus.



    Tu dis également que la propreté d'un makefile dépend de celui qui le cré comme si c'était un problème. Effectivement la propreté d'un makefile dépend de celui qui le cré, ce qui signifie que sous Unix on peut avoir de la bonne programmation si le programmeur est bon.

    Alors que sous VC++ c'est le compilateur qui créé les fichiers dont nous avons parlé, sans qu'on lui demande rien. Et c'est cela que je critique. C'est ce comportement _par défaut_. Forcément si tu cherches bien tu peux toujours modifier l'environnement pour qu'il te convienne mieux, mais j'insiste, le comportement par défaut est très révélateur de la philosophie de programmation sous un environnement parce-qu'il est le plus largement adopté.

    D'une certaine facon je ne pense pas que l'on soit porfondément en désaccord, je pense plutot que l'on est chacun axé sur des problèmatique différente.
  • [^] # Re: interet d'une IDE sous Linux

    Posté par  . En réponse à la dépêche C++ Builder sous Linux : bientôt du neuf !. Évalué à 1.

    Dans un source tu as que de l'information utile. Après quand tu compiles il y a plein de fichiers qui se créent, mais il suffit de faire un make clean pour que ces fichiers soient supprimés. Et en regardant le makefile tu peux avoir la liste compète de ces fichiers. C'est propre et rigoureux.

    Apparemment sous VC++ tu dois regarder toi-même quels sont les fichiers générés par VC++, regarder à quoi ils servent et les supprimer si nécessaires.

    De pluls les makefiles ont l'avantage d'être générique. Comprendre les makefiles, revient à comprendre les principes inhérents à _toute_ compilation. Comprendre VC++ revient à comprendre VC++. Comprendre Borland C++ revient à comprendre Borland C++, ...

    Sous windows, on n'a pas cette notion d'outil générique, comme make et les centaines de commandes Unix qui permettent d'apporter des solutions rapides et efficaces aux problèmes que l'on se pose. Ainsi j'ai moins de réticence à apprendre comment fonctionne make par rapport à VC++ car je sais que une fois compris les principes de make je pourrais utilisé cet outil dans de nombreuses situations très différentes les unes des autres.

    Je suis peut-être un peu borné quand il s'agit de Windows mais j'ai mes raisons (le seul avantage que je trouve à Windows est une meilleur finalisation des produits, ce qui est d'ailleurs très important et à tendance à manquer dans le libre).
  • [^] # Re: interet d'une IDE sous Linux

    Posté par  . En réponse à la dépêche C++ Builder sous Linux : bientôt du neuf !. Évalué à 1.

    Je me suis peut-être mal exprimé.
    Quand j'écris :
    "fichier généré dans le code source contenant la configuration de l'IDE !"
    je ne veux pas dire que la config est dans les fichiers sources mais quelle est située dans le meme répertoire que celui des fichiers sources.

    Sinon pour les fichiers générés j'ai les memes que toi avec en cadeau bonus, un fichier aps de ... roulement de tambour ... 3 Mo !
    Je sais pas à quoi il sert, on est sous windows, le compilo fait plein de truc et ne t'explique pas le pourquoi du comment. Alors peut-etre que je suis un ignorant, mais la philosophie Windows est justement de rendre les gens ignorant.
    Et puis de toute facon comme je compte ne plus jamais programmer sous Windows, je m'en tape pas mal de savoir à quoi peu bien servir ce fichier aps. Enfin si tu le sais tu peux toujours me le dire.

    Nibbles.aps 3Mo
    Nibbles.ncb 74 Ko
    Nibbles.opt 48Ko
    Nibbles.dsp 6 Ko
    Nibbles.plg 1Ko
    Nibbles.dsw 539Ah oui dernière chose, n'hésite pas à m'incendier si tu es pas d'accord avec moi, histoire de m'obliger à répondre et de faire monter mes XP (C'est dur d'etre un nouveau sur linuxfr !)
  • [^] # Re: interet d'une IDE sous Linux

    Posté par  . En réponse à la dépêche C++ Builder sous Linux : bientôt du neuf !. Évalué à 4.

    Perso je suis bien content de me retrouver au meme endroit que la derniere fois quand j'ouvres un fichier
    Disonc que ca serait bien qu'il sépare clairement l'information de configuration de l'information utile. Peut-etre est-ce possible si l'on change les options, en tout cas sur ma version ce n'est pas l'option par défaut.
    Et je trouve scandaleux d'avoir à se trimbaler des fichiers de configuration de 3 Mo quand le programme fait 40 Ko. Certes j'ai de la place sur mon disque. Mais je peux avoir le besoin d'envoyer mes programmes aux autres développeurs qui travaillent dessus et la les fichiers de conf de 3 Mo ils vont devenir vraiment casse couille.
    Certes si on cherche bien on doit pouvoir organiser tout ca de facon un peu plus propre mais les options par défauts ne nous contraigne pas à avoir une telle attitude. Et c'est pour ca que je parle d'assistanat dans le mauvais sens su terme.
    Le coté plus abrupte d'Unix force les gens à etre plus structuré dans leurs méthodes de travail et plus minimaliste. Or la perfection est atteinte lorsqu'il n'y a plus rien à enlever et ca sous VC et sous Windows en général on n'en n'a pas conscience.

    Notes qui si tu prenais la peine de voir ce que VC++
    Lorsque j'avais utilisé VC++ j'y avais été contraint et forcé, et pour que j'explore toutes les fonctionnalités d'un soft il faut que j'y prenne gout et la ce n'était vraiment pas le cas. Cela dit les options par défauts sont assez significatives de la philosophie de développement.

    L'assistanat c'est au contraire bien pratique
    Oui mais il faut séparer la partie assistanat (IDE, fichier de configuration de l'IDE, ...) du code source et ne pas tout mélanger comme le fait VC++ (fichier généré dans le code source contenant la configuration de l'IDE !).
  • [^] # Re: interet d'une IDE sous Linux

    Posté par  . En réponse à la dépêche C++ Builder sous Linux : bientôt du neuf !. Évalué à 3.

    Avec l'expérience tu en as un peu marre de perdre du temps avec ces conneries de makefiles et autres autoconf

    L'avantage de la méthodologie Unix c'est que tu controles __toute__ l'information de tes sources. Il n'y a rien qui soit génréré automatiquement. Je suis en train de porter un programme que j'avais écris en Visual C en gtk+ et je peux vous dire quel bonheur de devoir supprimer toutes cette multitude de fichiers, souvent d'une taille inacceptable, généré par VC et qui sont d'une utilité plus que douteuses. Lorsque l'on développe sous Windows, on écrit 3 lignes de code, on sauve et on se retrouve avec des Mo de fichiers stockant des information aussi inutiles que la position de notre curseur dans chacun des fichiers que l'on a ouvert au moment ou l'on a quitté l'application.
    En autre terme Unix, c'est la maitrise, Windows c'est l'assistanat. Et l'assistanat, en France on est bien placé pour le savoir, cré beaucoup de dégats.
  • [^] # Re: Bizarre...

    Posté par  . En réponse à la dépêche quand AMD retrouve Intel .... Évalué à -5.

    4ko les pages, pas 4 Mo !