La VM est chargée d'exécuter alors que le compilateur produit du code autonome. Dans le code produit par le compilateur, rien n'empèche d'intégrer une sorte de profiler/optimiseur et ainsi choisir d'inliner certaines fonctions/boucles de la même manière qu'une bonne VM. Ca peut paraître compliqué, mais si une VM peut le faire, un compilo aussi.
Pour en revenir à la spécialisation de code, il y a un exemple assez intéressant qui faisait partie des tests: prenons la fonction int interpreter(char* bytecode, int size), chargée d'interpréter du bytecode Java. Le test consistait à spécialiser cette fonction en donnant au spécialiseur le bytecode... résultat, on obtenait une fonction sans paramètre qui n'était autre qu'une version compilée du bytecode!! Grace à ce projet, il suffit donc d'écrire l'interpréteur d'un langage pour obtenir en quelques commandes un compilateur pour ce même langage :-) C'est-y pas beau.
Quand tu fais de la compilation classique, tu vas dire au compilo de mettre telles et telles fonctions en inline
Tu parles justement de compilation classique... Si un VM est capable d'optimiser des fonctions par rapport aux données du programme exécuté, qu'est-ce qui empêche le compilateur de générer du code capable de ces même "prouesses"?
Il y a quelques temps, j'ai bossé sur un projet dont l'un des buts est justement d'obtenir de la génération de code à la volée, en fonction de paramètres donnés pendant l'exécution. Pour l'instant c'est hyper lourd à mettre en place, mais les principes sont là. http://compose.labri.fr/prototypes/tempo/(...)
Ce n'est qu'un exemple, mais un collègue a voulu participer au développement de l'install de la Woody; il a fait quelques modifs de façon à pouvoir choisir la langue et le clavier par défaut lors de la génération des CD d'install. Quand il a proposé le patch, un des responsables lui a rit au nez en lui disant que c'était complètement inutile; depuis, le patch a été intégré sans que son auteur ne soit contacté... J'aime bien les principes des distributions Debian, mais faut avouer que ce genre de gestion de projet ne donne pas franchement envie d'aider.
J'insiste: ce n'est qu'un exemple, faut pas non-plus généraliser et ce n'est pas ça qui va me faire échanger ma Debian contre deux barils de RedHat.
Haaa, enfin quelqu'un qui parle posément, sans forcer sur le troll. Pour ma part, quand je m'intéressait aux développements sur la 3D, beaucoup de bonnes doc se trouvaient sur le site R&D Microsoft, où certaines techniques utilisées aujourd'hui dans des jeux comme Black&White étaient expliquées avec quelques années d'avance, le tout gratuitement!! Les idées proposées par MS ne sont pas toutes pourries comme certains le crient un peu trop fort, mais entre l'idée et l'implémentation il y a bien souvent trop de marge et ça finit en n'importe quoi, ce qui est regrettable pour les acheteurs, mais intéressant pour le libre qui y récupère parfois quelques idées (et aussi des clients :-).
Le truc qui m'embête dans ce que tu dis, c'est:
ca devrait finir par aller plus vite que du code compilé par exemple
Bondieu d'bondieu d'bondieu: comment un code interprété peut-il être plus rapide qu'un code compilé? Je veux bien admettre que les VM fassent des progrès, mais ce n'est pas une raison pour imaginer que les compilateurs vont se dégrader pendant ce temps là...
Le jour où les processeurs comprendront le bytecode Java, il ne devrait plus y avoir de différence, mais en attendant les compilateurs auront toujours le moyen de faire du code plus performant que n'importe quel interpréteur.
Bon, à part critiquer les critiques, y'aurait pas autre chose de plus constructif à faire, comme répondre aux critiques de façon constructive (avec des arguments). Si un commentaire ne vous plaît pas, dites-le, et surtout dites pourquoi, histoire qu'on puisse en débattre... mais c'est bien plus simple de grogner (troller?).
Un Makefile bien écrit associé à un "gcc -m" bien placé et le tour est joué. Bien souvent, quand je refais les Makefile d'un projet existant, les développeurs sont contents... (ça me fait un peu mal aux chevilles de dire ça, mais bon c'est la vérité)
il en sort de vrais génies qui résolvent d'un coup un problème qui fait chier toute l'industrie depuis des années
C'est pas de ma faute si je comprends certains outils mieux que des personnes qui ont plus d'années de développement derrière elles. Ce que je constate, c'est que la fainéantise de certains développeurs les pousse à utiliser ce qui existe, sans chercher à faire mieux que ce qu'ils savent utiliser alors que ça leur permettrait d'être encore plus fainéant.
La notion de fichier source n'a rien à voir avec la programmation en soi
Pour l'instant, l'indépendance n'est pas flagrante à mes yeux. Je me base sur l'utilisation du Visual C++ dans différents projets. A mon avis, il n'est pas dans l'intérêt des développeurs d'utiliser un IDE qui utilise son propre format pour rassembler sources et projet dans un même fichier, mais c'est juste mon avis (il y a sûrement des exceptions pour confirmer ce que je dis...).
je serais très étonné que tu ais la moindre expérience de développement en entreprise
Va falloir que je revérifie ce que j'ai fait depuis quelques années... je passe peut-être trop de temps sur DLFP mais j'ai quand même le temps de faire mon boulot de développeur.
Quand tu développes en équipe, tout le monde utilise les mêmes outils
Quand tu lances un développement, tu ne peux pas savoir à l'avance toutes les taches qu'il sera bon d'automatiser. Ca se fait petit à petit en utilisant les outils que les autres ont déjà mis en place pour se simplifier la vie. Oui tout le monde est sensé utiliser les mêmes outils, ça n'empêche pas de chercher à se simplifier le travail puis de proposer ses petits scripts aux autres développeurs.
Preuve que les neuneux ne sont pas forcément tous sous Windows
Ha bon, t'es pas sous Windows :-) (désolé, elle était trop facile)
MS c'est mal
Tu me trouves où j'ai dit ça ou tu arrêtes de me prendre pour un con. Quand j'explique que les outils Microsoft forcent l'utilisation de certaines méthodes de travail, je ne dis pas que c'est de la merde. Le outils libres impliquent aussi des méthodes de travail, la différence étant que l'éventail des possibilités est plus large avec le libre (à mon avis).
.Net c'est de la merde
Je n'ai pas dit ça, le principe de .Net est bon: simplifier la vie du développeur, je ne peux pas être contre en tant que développeur; par contre, je me base sur des outils comme le Visual C++ que j'ai pas mal utilisé (et qui m'a bien plu pour commencer à développer, mais qui m'a rapidement freiné par rapport à ce que j'arrive à faire maintenant avec les outils libres) et j'imagine, peut-être à tort, que MS va reprendre de principe du développement assisté à base de clicodrome.
Miguel est un enfoiré
Là, tu me pêtes les couilles (je suis désolé de la grossièreté, mais au moins le message est clair). Soit tu réponds à mon commentaire, et je n'ai jamais parlé de Miguel, soit tu réponds à ceux qui disent que Miguel raconte n'importe quoi. Pour ma part, Miguel peut dire ce qu'il veut, aucun décideur n'est capable de dire ce que sera l'informatique dans 2 ans donc j'évite de débattre ce que les Nostradamus modernes racontent.
Vous ne voulez surtout pas qu'on remette en cause vos petites convictions de rebelles à 2cents
/sbin/trolld: segfault
C'est à cause de gens comme vous que Linux a tant de mal à s'imposer
/sbin/trolld: respawning too fast
On a jamais fait avancer les choses avec une paire d'oeillères sur la tête
C'est con que tu dises ça à moi, je développe autant sous Windows que sous Linux (avec un ch'tit peu d'HP-UX et de Solaris, mais ça ne compte pas assez pour que je puisse parler de ces systèmes à part pour dire que je n'ai pas été franchement emballé)... je me considère tout de même assez bien placé pour faire des comparaisons. Ce n'est pas avoir des oeillères que de donner son avis avec des arguments, par ça l'est de répondre à cet avis avec des troll et des attaques à deux balles qui n'ont rien à voir avec ce qui est raconté.
Toi, quand tu ne veux pas comprendre quelque chose, tu es champion... je t'explique qu'avec les outils de développement Microsoft, les développeurs ont généralement leur tâche facilitée (donc atteignent leur vitesse de croisière en peu de temps), mais pas autant qu'un développeur qui met en place son environnment de travail étudié au type de développement qu'il est en train de réaliser. Grace à Microsoft, les décideurs anticipent rapidement sur la vitesse de développement de leur personnel: c'est la même vitesse dès les premiers jours, alors qu'avec les outils libres, chacun se met en place ses outils, ses scripts/Makefiles et après quelques jours (bien souvent, ça se met en place en cours de développement) la productivité est bien meilleure. Les deux possibilités sont acceptables (je ne parle pas du résultat, juste de la méthode de travail) et ne se valent pas sur une même durée de projet.
ils gagnent du temps en n'ayant plus a creer des wrappers
Tu te trompes de commentaire: d'autres t'ont déjà expliqué ailleurs qu'il y a des outils qui créent les wrappers automatiquement, donc ils n'ont plus à être créés à la main. Rendre automatique ce qui est déjà automatique sur d'autres systèmes, voila la grande nouveauté de .Net??
Bon, encore une fois, tu n'es là que pour pourrir le débat (à part nous dire que c'est mieux parce que ça fait ce que l'on sait déjà faire, tu n'avance aucun argument). Je suis désolé d'avoir une opinion de tes commentaires qui me forcent à éviter de lire ce que tu racontes (tout n'est pas c*n, mais dans la globalité je ne comprends même pas que l'on puisse soutenir des positions comme celles que tu cherches parfois à défendre) donc je laisse tomber le débat... désolé, mais comme on dit poliment: «tu m'énerves» à ne faire avancer que tes idées, sans regarder que bien souvent les autres détruisent les principes sur lesquelles tes idées reposent (et ne me demande pas d'exemples, je n'en ai pas sous la main et je n'ai pas envie de chercher pendant des plombes vu que tu nieras tout et relanceras d'autres idées, comme d'hab.).
Je te dis simplement que ce sera 10 fois plus facile avec .NET
Le problème, c'est que facilité ne va pas très bien avec efficacité: prenons deux personnes qui n'ont presque jamais touché un ordi et demandons leur de faire un rapport/une thèse, l'une avec MS Word et l'autre avec LaTex... Dans les premiers jours, l'utilisateur de Word ira sûrement plus vite que l'autre (les clicodromes, quoi qu'on en pense, facilitent le travail), mais après quelques temps, l'utilisateur LaTex se sera mis en place son petit environnement, aura compris quelques principes de la mise en page et finalement avancera bien plus plus vite que l'autre utilisateur (les clicodromes sont faciles à utiliser mais ne poussent pas les utilisateurs à apprendre de nouvelle façon de faire ce qu'ils savent faire)... LaTex n'est franchement pas facile quand on le découvre mais il est bien plus efficace une fois qu'on le connaît.
Ce que Microsoft nous propose, c'est d'automatiser l'interfaçage entre les langages... ce sera peut-être plus facile qu'en lançant tout plein de commandes à la main comme actuellement, mais je ne pense pas que ça puisse devenir plus facile à utiliser que des Makefile bien faits dans une arborescence bien étudiée. .Net va sûrement plaire à ceux qui développaient en VB et qui veulent passer à d'autres langages plus performants, mais je ne pense pas que ça intéresse les développeurs qui ont déjà un niveau suffisant pour savoir tapper:
> cd $PROJET/src/gui
> make cpp-interfaces
> cd $PROJET/src/core
> make py-interfaces
> cd $PROJET/src
> make
Bien sûr, rien n'empêche de mettre ces commandes dans un script (ou dans le Makefile principal) et d'associer ce script à un bouton dans son éditeur clocodrome préféré. Je préfère me simplifier le travail à ma façon mais faut admettre que l'utilisateur lambda n'en a généralement pas le temps (ou la volonté).
Ça fait 8 ans que je code sous Unix, et les makefiles restent toujours un problème [...] ainsi que pour tous les développeurs dans toutes les boites où j'ai pu bosser
Ben, ça ne fait que 2 ans que je suis sorti de fac et il est vrai que je donne des cours de Makefile dans quelques sociétés alors qu'il y a un an je ne connaissais que le principe... enfin, quand je parle de cours, j'écris les Makefile puis je leur explique qu'il suffit de taper "make opt" ou "make debug" pour obtenir les sources puis "make install" avant de lancer les tests. Comme bien souvent, cela reste trop difficile, je suis obligé d'intégrer ces commandes dans leur XEmacs (que les developpeurs ont aussi bien du mal à utiliser en général).
Les Makefile, c'est comme Unix et pas mal d'outils comme sed, awk, vi...: quand on ne cherche pas à comprendre, on ne comprend pas, et une fois qu'on comprend, on se rend compte que c'est hyper simple!! C'est juste une façon de réfléchir.
[browser de code/méthode de travail] ça n'a pas grand chose à voir
Ben, quand même un peu. Quand il y a un outil pour naviguer rapidement dans les classes, on a tendance à ne pas s'embêter à organiser les sources... et du coup un simple grep ne suffit pas, je suis bien d'accord. Tout est une question de méthode de travail, et il n'est pas simple de se séparer de la méthode de travail proposée (imposée?) par le Visual C++; personnellement, il m'a fallu un moment, mais je me sens bien mieux... plus libre.
Avec l'expérience tu en as un peu marre de perdre du temps avec ces conneries de makefiles et autres autoconf
Avec l'expérience, tu apprends à générer ce genre de fichier en quelques minutes, et de façon durable (ne pas avoir à tout revérifier à chaque fois). Un browser de méthodes/fonctions ne remplacera jamais une méthode de travail claire et rapidement compréhensible par d'autres, j'aurais même tendance à ajouter «au contraire»: quand je vois des projets développés sous Visual C++ avec un grand nombre de classes et juste 3 ou 4 fichiers source dans le projet, je me dis que si le développeur avait eu à rechercher les classes/méthodes à la main, il aurait pris l'habitude de mieux ranger son code...
Les interfaces de navigation dans le code facilitent le travail mais ne le rendent pas plus propre, au contraire (cette fois-ci, je n'hésite pas à le dire).
j'ai déja vu des développeurs "C" sous "vi" qui étaient persuadé qu'en C++ il y'a un garbage collector
et??? Moi j'ai déjà vu des momes qui croyaient au Père Noël...
Tous ceux qui critiquent vi sont ceux qui ne le connaissent pas assez ou qui croient que quand on a un outils il faut toujours s'en servir («quand le seul outils que l'on possède est un marteau, on a tendance à voir les problèmes comme des clous» disait je ne sais qui). Personnellement, je développe sous XEmacs, et j'édite les fichiers de conf (ou les petites modifs dans les sources) à l'aide de vim... J'ai une connaissance assez médiocre des techniques de la mort de chacun de ces outils, mais je sais à peu près quand utiliser l'un ou l'autre.
le manque d'IDE sous Linux est effectivement un obstacle à ma productivité
Linux ne manque pas d'IDE, mais il n'y a pas d'IDE à la Visual C++ sous Linux (et encore, KDevelopp à l'air de s'en approcher un peu trop :-) Pour débuter, on a besoin d'avoir des règles de développement, des méthodes de travail, et le Visual C++ force à en avoir certaines, mais avec l'expérience, on est bien content de pouvoir se faire son propre environnement à base de makefiles, gcc, gdb (parfois ddd, mais pas trop quand même), autoconf, dpkg-buildpackage...
Comparer l'environnement Visual C++ à vi, ça c'est un joli troll, presque autant que de comparer XEmacs (notez le X) à vi...
Tu as l'air de penser que tout avis a forcément un argument?!! «J'aime pas le nutella», c'est quand même bien un avis, par contre tu peux toujours chercher l'argument. Pour moi le premier point est un avis (trollesque, j'insiste!) sur les logiciels propriétaires payants avec une version gratuite + bandeau, et non un argument expliquant pourquoi il n'aime pas Opera (ou alors c'est un avis du style «j'aime pas le nutella parce que c'est une pate à tartiner», le seul argument étant que le nutella est ce qu'il est, une pate à tartiner).
Quand quelqu'un me dit qu'il n'aime pas Windows parce que c'est payant, je le remets à sa place: Windows n'est pas bien parce que le niveau de sécurité/stabilité de ce produit est lamentable (et donc ne devrait pas être vendu, mais l'argument n'est pas là). Moi aussi je trouve qu'Opera est trop cher pour ce qu'il est stable, n'empèche que sa version gratuite avec bandeau est bien rapide et pas trop buggée quand je la compare à Mozilla (attention, j'utilise aussi Mozilla que je trouve suffisament stable face à un IE qui n'arrive pas à respecter la moitié des normes W3C correctement). Personne n'oblige dva (ou n'importe quel autre utilisateur privé de liberté) à utiliser Opera mais il a tout à fait le droit de dire qu'il regrette que la version gratuite ait un bandeau, ce qui n'en fait pas un argument pour dire si Opera est bien ou pas.
Comme d'hab, il semblerait que l'on soit d'accord sur le fond, mais pas sur la forme, et je suis très chiant sur la forme: les meilleurs trolls sont ceux qui jouent sur la forme (un troll n'est pas forcément un mensonge, je le rappelle). Quand Microsoft parle de la GPL en tant que license virale, je trouve les termes employés aussi bien choisis que quand un autre dit que Windows est de la merde: c'est vrai, mais il y a quand même des façons un peu moins lourdes de le dire (là, je rentre dans le politiquement correct, faut que je fasse gaffe).
J'espère que tu voulais dire interfaces externes ;-D Car si tu antispoof les internes (et bloque 192.168.X.X et 10.X.X.X) tu n'es pas bien...
C'est ici que commencent tes posts insignifiants? Parce que pour quelqu'un qui s'y connaît, il s'agit quand même d'une belle bêtise.
Le seul commentaire de toi que je vois avant celui-là dans ce thread, c'est le commentaire où tu donnes quelques URLs (sûrement très intéressantes, mais ne t'obligeant pas à raconter et soutenir n'importe quoi par la suite).
Sur la "lan", ce n'est pas de l'anti spoofing de se réduire aux adresses locales, en effet n'importe qui peut changer très facilement d'adresse locale (excepté si on teste les adresses mac mais rarement exploitable).
Là, c'est sûr, tu venais de fumer la moquette avant d'écrire cette phrase... Empêcher un paquet dont l'adresse source n'appartient pas au lan1 de passer du lan1 au lanX, ce n'est pas de l'antispoofing d'après toi?
Le reste du commentaire est navrant de bêtise et je ne préfère pas en parler. Si c'est un troll que tu voulais faire, je ne le trouve pas des plus réussi au niveau finesse (même s'il a quand même eu une belle efficacité).
Ensuite arrive le coup du firewall connecté à un seul réseau... bon, d'accord, tout le monde avait compris que tu voulais dire un seul réseau privé, mais ce serait quand même bien de prendre le temps de se relire. Toujours est-il que j'ai préféré te faire préciser la question plutôt que de répondre à ce qui me semblait assez trivial: l'explication reste valable si l'on retire une des pates au firewall ou qu'on en rajoute une centaine.
mes posts précédents montrent, il me semble que j'y connais quelque chose
Ben, désolé, mais sur ce thread, pas trop...
Cela n'aurait pas du produire de réaction
Tu peux préciser pourquoi? j'ai du mal à suivre: si tu fais des trolls dans le but de ne pas avoir de réaction, pourquoi donc alors? et si tu étais vraiment sérieux quand tu as posté tes bêtises, penses-tu vraiment que ça n'aurait pas du entrainer de correction?
Bon, on va arrêter de jouer parce que tu t'enfonces de plus en plus... je vais aller voir ce que tu as raconté sur les clients ssh (il paraît qu'il faut un serveur X pour faire du X11 forwarding :-)
Pour ma part, je ne l'ai pas vraiment appris, mais tes commentaires me confirment que certaines personnes sont tellement sures d'elles qu'elles sont capables de défendre des idées auquelles personnes ne peut adhérer puisque d'autres se sont déjà chargés de les contredire avec des arguments en béton.
Tout le monde dit des bêtises de temps à autre, soit parce que ses idées sont mal écrites, soit parce que le sujet n'est pas maîtrisé dans son ensemble, soit parce que ce sont des bêtises tout court. Il faut savoir admettre quand on dit une bêtise et avoir le courage de dire pourquoi.
Dans ton cas, tu as tellement voulu défendre tes idées face à des arguments que tu n'as même pas cherché à nier que ça en devient ridicule. Les gens ont de la patience, mais faudrait voir à ne pas en abuser non plus, et même si tu n'insultes personnes avec tes posts à deux cents, faut quand même avouer que tu commences à nous les briser.
Ca m'embête d'en arriver à de telles grossièretés, mais je n'aime pas que l'on se foute de la gueule de ceux qui prennent le temps d'expliquer.
Dans le premier point, dva nous fait une description d'Opera en n'oubliant pas de faire ressortir l'idée qu'il n'aime pas les logiciels qui sont apparus d'abord sous Windows puis ensuite sous Linux, et en signalant que le bandeau de pub l'embête (sinon, pourquoi exagérer au piont de le faire mesurer 3km). Pour moi, c'est son avis, présenté de façon trollesque; je n'ai jamais dis qu'il n'était pas bon, j'ai juste dit qu'un avis sans argument ne vaut pas grand chose (pas plus que n'importe quel autre avis sans argument).
Si pour toi le premier point est un argument, il faut me dire pour ou contre quoi: contre les logiciels commerciaux? contre les logiciels avec commerciaux qui ont une version gratuite? contre les logiciels gratuits qui ont des banières (sur mon écran, elle fait 10cm, pas 3km)? contre les logiciels payants?
On peut parler des logiciels commerciaux sans dire "ce truc honteusement payant avec ses hectares de publicité", tout comme il est possible de parler de la GPL sans dire "cette mauvaise license à tendances virales".
je ne comprend pas ton opposition entre avis et argument
Hein? J'ai opposé avis et argument? J'ai rapproché l'avis sans argument d'une personne et la non présence d'arguments dans la réponse à cet avis, ce qui est loin d'être la même chose.
Lorsqu'on a un avis, on le justifie en argumentant, c'est ça le principe, non ?
Tout à fait. Et tout ce que j'ai demandé, ce sont des arguments expliquant pourquoi dva n'aime pas Opera.
Dans l'explication que j'ai donnée au dessus, élimines l'interface dmz0 et reprends la question: est-ce que tu trouves normal que l'interface lan0 du firewall accepte en entrée un paquet dont l'adresse IP source ne fait pas partie du réseau lan0?
La réponse reste la même: le paquet doit être refusé. Le firewall ne doit pas accepter en entrée un paquet n'ayant rien à faire sur l'interface qui le reçoit: l'interface lan0 refuse en entrée tout ce qui ne vient pas de 192.168.1.xxx tout comme l'interface wan0 refuse en entrée tout ce qui ne provient pas d'une IP routable sur internet.
[^] # Re: La sécurité avance !
Posté par pas_moi . En réponse à la dépêche kitetoa condamné. Évalué à 10.
Y'a plus qu'une chose à faire: boycoter Tati (de toute façon, ça ne se trouve que sur Paris ces trucs là, non?).
[^] # Re: BitKeeper n'est pas libre...
Posté par pas_moi . En réponse à la dépêche Linus passe un peu la main. Évalué à 10.
Hummm, et surtout ils ne disent pas grand chose d'exact! Pour chaque fonctionnalité, ils comparent BK avec ce qui se fait de pire en proprio...
[^] # Re: S'il vous plait arretez avec votre Open Source !
Posté par pas_moi . En réponse à la dépêche Linus passe un peu la main. Évalué à 10.
[^] # Re: BitKeeper n'est pas libre...
Posté par pas_moi . En réponse à la dépêche Linus passe un peu la main. Évalué à 10.
Tu trouves ça trop compliqué ou quoi?
[^] # Il ne faut pas confondre...
Posté par pas_moi . En réponse à la dépêche Firewall toujours en fonction sur un Linux arrêté!. Évalué à 1.
s/efficace/préemptif/
[^] # Re: Oui, mais...
Posté par pas_moi . En réponse à la dépêche Miguel DeIcaza et .NET. Évalué à 2.
La VM est chargée d'exécuter alors que le compilateur produit du code autonome. Dans le code produit par le compilateur, rien n'empèche d'intégrer une sorte de profiler/optimiseur et ainsi choisir d'inliner certaines fonctions/boucles de la même manière qu'une bonne VM. Ca peut paraître compliqué, mais si une VM peut le faire, un compilo aussi.
Pour en revenir à la spécialisation de code, il y a un exemple assez intéressant qui faisait partie des tests: prenons la fonction int interpreter(char* bytecode, int size), chargée d'interpréter du bytecode Java. Le test consistait à spécialiser cette fonction en donnant au spécialiseur le bytecode... résultat, on obtenait une fonction sans paramètre qui n'était autre qu'une version compilée du bytecode!! Grace à ce projet, il suffit donc d'écrire l'interpréteur d'un langage pour obtenir en quelques commandes un compilateur pour ce même langage :-) C'est-y pas beau.
[^] # Re: Oui, mais...
Posté par pas_moi . En réponse à la dépêche Miguel DeIcaza et .NET. Évalué à 2.
Tu parles justement de compilation classique... Si un VM est capable d'optimiser des fonctions par rapport aux données du programme exécuté, qu'est-ce qui empêche le compilateur de générer du code capable de ces même "prouesses"?
Il y a quelques temps, j'ai bossé sur un projet dont l'un des buts est justement d'obtenir de la génération de code à la volée, en fonction de paramètres donnés pendant l'exécution. Pour l'instant c'est hyper lourd à mettre en place, mais les principes sont là. http://compose.labri.fr/prototypes/tempo/(...)
[^] # Re: Ca n'a pas l'air rose...
Posté par pas_moi . En réponse à la dépêche Debian Weekly News - January 30th, 2002. Évalué à 3.
Ce n'est qu'un exemple, mais un collègue a voulu participer au développement de l'install de la Woody; il a fait quelques modifs de façon à pouvoir choisir la langue et le clavier par défaut lors de la génération des CD d'install. Quand il a proposé le patch, un des responsables lui a rit au nez en lui disant que c'était complètement inutile; depuis, le patch a été intégré sans que son auteur ne soit contacté... J'aime bien les principes des distributions Debian, mais faut avouer que ce genre de gestion de projet ne donne pas franchement envie d'aider.
J'insiste: ce n'est qu'un exemple, faut pas non-plus généraliser et ce n'est pas ça qui va me faire échanger ma Debian contre deux barils de RedHat.
[^] # Re: Oui, mais...
Posté par pas_moi . En réponse à la dépêche Miguel DeIcaza et .NET. Évalué à 5.
Haaa, enfin quelqu'un qui parle posément, sans forcer sur le troll. Pour ma part, quand je m'intéressait aux développements sur la 3D, beaucoup de bonnes doc se trouvaient sur le site R&D Microsoft, où certaines techniques utilisées aujourd'hui dans des jeux comme Black&White étaient expliquées avec quelques années d'avance, le tout gratuitement!! Les idées proposées par MS ne sont pas toutes pourries comme certains le crient un peu trop fort, mais entre l'idée et l'implémentation il y a bien souvent trop de marge et ça finit en n'importe quoi, ce qui est regrettable pour les acheteurs, mais intéressant pour le libre qui y récupère parfois quelques idées (et aussi des clients :-).
Le truc qui m'embête dans ce que tu dis, c'est:
ca devrait finir par aller plus vite que du code compilé par exemple
Bondieu d'bondieu d'bondieu: comment un code interprété peut-il être plus rapide qu'un code compilé? Je veux bien admettre que les VM fassent des progrès, mais ce n'est pas une raison pour imaginer que les compilateurs vont se dégrader pendant ce temps là...
Le jour où les processeurs comprendront le bytecode Java, il ne devrait plus y avoir de différence, mais en attendant les compilateurs auront toujours le moyen de faire du code plus performant que n'importe quel interpréteur.
[^] # Re: Oui, mais...
Posté par pas_moi . En réponse à la dépêche Miguel DeIcaza et .NET. Évalué à 1.
[^] # Re: interet d'une IDE sous Linux
Posté par pas_moi . En réponse à la dépêche C++ Builder sous Linux : bientôt du neuf !. Évalué à 1.
Un Makefile bien écrit associé à un "gcc -m" bien placé et le tour est joué. Bien souvent, quand je refais les Makefile d'un projet existant, les développeurs sont contents... (ça me fait un peu mal aux chevilles de dire ça, mais bon c'est la vérité)
il en sort de vrais génies qui résolvent d'un coup un problème qui fait chier toute l'industrie depuis des années
C'est pas de ma faute si je comprends certains outils mieux que des personnes qui ont plus d'années de développement derrière elles. Ce que je constate, c'est que la fainéantise de certains développeurs les pousse à utiliser ce qui existe, sans chercher à faire mieux que ce qu'ils savent utiliser alors que ça leur permettrait d'être encore plus fainéant.
La notion de fichier source n'a rien à voir avec la programmation en soi
Pour l'instant, l'indépendance n'est pas flagrante à mes yeux. Je me base sur l'utilisation du Visual C++ dans différents projets. A mon avis, il n'est pas dans l'intérêt des développeurs d'utiliser un IDE qui utilise son propre format pour rassembler sources et projet dans un même fichier, mais c'est juste mon avis (il y a sûrement des exceptions pour confirmer ce que je dis...).
[^] # Re: Oui, mais...
Posté par pas_moi . En réponse à la dépêche Miguel DeIcaza et .NET. Évalué à 1.
[^] # Re: Oui, mais...
Posté par pas_moi . En réponse à la dépêche Miguel DeIcaza et .NET. Évalué à 8.
Va falloir que je revérifie ce que j'ai fait depuis quelques années... je passe peut-être trop de temps sur DLFP mais j'ai quand même le temps de faire mon boulot de développeur.
Quand tu développes en équipe, tout le monde utilise les mêmes outils
Quand tu lances un développement, tu ne peux pas savoir à l'avance toutes les taches qu'il sera bon d'automatiser. Ca se fait petit à petit en utilisant les outils que les autres ont déjà mis en place pour se simplifier la vie. Oui tout le monde est sensé utiliser les mêmes outils, ça n'empêche pas de chercher à se simplifier le travail puis de proposer ses petits scripts aux autres développeurs.
Preuve que les neuneux ne sont pas forcément tous sous Windows
Ha bon, t'es pas sous Windows :-) (désolé, elle était trop facile)
MS c'est mal
Tu me trouves où j'ai dit ça ou tu arrêtes de me prendre pour un con. Quand j'explique que les outils Microsoft forcent l'utilisation de certaines méthodes de travail, je ne dis pas que c'est de la merde. Le outils libres impliquent aussi des méthodes de travail, la différence étant que l'éventail des possibilités est plus large avec le libre (à mon avis).
.Net c'est de la merde
Je n'ai pas dit ça, le principe de .Net est bon: simplifier la vie du développeur, je ne peux pas être contre en tant que développeur; par contre, je me base sur des outils comme le Visual C++ que j'ai pas mal utilisé (et qui m'a bien plu pour commencer à développer, mais qui m'a rapidement freiné par rapport à ce que j'arrive à faire maintenant avec les outils libres) et j'imagine, peut-être à tort, que MS va reprendre de principe du développement assisté à base de clicodrome.
Miguel est un enfoiré
Là, tu me pêtes les couilles (je suis désolé de la grossièreté, mais au moins le message est clair). Soit tu réponds à mon commentaire, et je n'ai jamais parlé de Miguel, soit tu réponds à ceux qui disent que Miguel raconte n'importe quoi. Pour ma part, Miguel peut dire ce qu'il veut, aucun décideur n'est capable de dire ce que sera l'informatique dans 2 ans donc j'évite de débattre ce que les Nostradamus modernes racontent.
Vous ne voulez surtout pas qu'on remette en cause vos petites convictions de rebelles à 2cents
/sbin/trolld: segfault
C'est à cause de gens comme vous que Linux a tant de mal à s'imposer
/sbin/trolld: respawning too fast
On a jamais fait avancer les choses avec une paire d'oeillères sur la tête
C'est con que tu dises ça à moi, je développe autant sous Windows que sous Linux (avec un ch'tit peu d'HP-UX et de Solaris, mais ça ne compte pas assez pour que je puisse parler de ces systèmes à part pour dire que je n'ai pas été franchement emballé)... je me considère tout de même assez bien placé pour faire des comparaisons. Ce n'est pas avoir des oeillères que de donner son avis avec des arguments, par ça l'est de répondre à cet avis avec des troll et des attaques à deux balles qui n'ont rien à voir avec ce qui est raconté.
[^] # Re: Oui, mais...
Posté par pas_moi . En réponse à la dépêche Miguel DeIcaza et .NET. Évalué à 5.
ils gagnent du temps en n'ayant plus a creer des wrappers
Tu te trompes de commentaire: d'autres t'ont déjà expliqué ailleurs qu'il y a des outils qui créent les wrappers automatiquement, donc ils n'ont plus à être créés à la main. Rendre automatique ce qui est déjà automatique sur d'autres systèmes, voila la grande nouveauté de .Net??
Bon, encore une fois, tu n'es là que pour pourrir le débat (à part nous dire que c'est mieux parce que ça fait ce que l'on sait déjà faire, tu n'avance aucun argument). Je suis désolé d'avoir une opinion de tes commentaires qui me forcent à éviter de lire ce que tu racontes (tout n'est pas c*n, mais dans la globalité je ne comprends même pas que l'on puisse soutenir des positions comme celles que tu cherches parfois à défendre) donc je laisse tomber le débat... désolé, mais comme on dit poliment: «tu m'énerves» à ne faire avancer que tes idées, sans regarder que bien souvent les autres détruisent les principes sur lesquelles tes idées reposent (et ne me demande pas d'exemples, je n'en ai pas sous la main et je n'ai pas envie de chercher pendant des plombes vu que tu nieras tout et relanceras d'autres idées, comme d'hab.).
[^] # Oui, mais...
Posté par pas_moi . En réponse à la dépêche Miguel DeIcaza et .NET. Évalué à 10.
Le problème, c'est que facilité ne va pas très bien avec efficacité: prenons deux personnes qui n'ont presque jamais touché un ordi et demandons leur de faire un rapport/une thèse, l'une avec MS Word et l'autre avec LaTex... Dans les premiers jours, l'utilisateur de Word ira sûrement plus vite que l'autre (les clicodromes, quoi qu'on en pense, facilitent le travail), mais après quelques temps, l'utilisateur LaTex se sera mis en place son petit environnement, aura compris quelques principes de la mise en page et finalement avancera bien plus plus vite que l'autre utilisateur (les clicodromes sont faciles à utiliser mais ne poussent pas les utilisateurs à apprendre de nouvelle façon de faire ce qu'ils savent faire)... LaTex n'est franchement pas facile quand on le découvre mais il est bien plus efficace une fois qu'on le connaît.
Ce que Microsoft nous propose, c'est d'automatiser l'interfaçage entre les langages... ce sera peut-être plus facile qu'en lançant tout plein de commandes à la main comme actuellement, mais je ne pense pas que ça puisse devenir plus facile à utiliser que des Makefile bien faits dans une arborescence bien étudiée. .Net va sûrement plaire à ceux qui développaient en VB et qui veulent passer à d'autres langages plus performants, mais je ne pense pas que ça intéresse les développeurs qui ont déjà un niveau suffisant pour savoir tapper:
> cd $PROJET/src/gui
> make cpp-interfaces
> cd $PROJET/src/core
> make py-interfaces
> cd $PROJET/src
> make
Bien sûr, rien n'empêche de mettre ces commandes dans un script (ou dans le Makefile principal) et d'associer ce script à un bouton dans son éditeur clocodrome préféré. Je préfère me simplifier le travail à ma façon mais faut admettre que l'utilisateur lambda n'en a généralement pas le temps (ou la volonté).
[^] # Re: interet d'une IDE sous Linux
Posté par pas_moi . En réponse à la dépêche C++ Builder sous Linux : bientôt du neuf !. Évalué à 10.
Ben, ça ne fait que 2 ans que je suis sorti de fac et il est vrai que je donne des cours de Makefile dans quelques sociétés alors qu'il y a un an je ne connaissais que le principe... enfin, quand je parle de cours, j'écris les Makefile puis je leur explique qu'il suffit de taper "make opt" ou "make debug" pour obtenir les sources puis "make install" avant de lancer les tests. Comme bien souvent, cela reste trop difficile, je suis obligé d'intégrer ces commandes dans leur XEmacs (que les developpeurs ont aussi bien du mal à utiliser en général).
Les Makefile, c'est comme Unix et pas mal d'outils comme sed, awk, vi...: quand on ne cherche pas à comprendre, on ne comprend pas, et une fois qu'on comprend, on se rend compte que c'est hyper simple!! C'est juste une façon de réfléchir.
[browser de code/méthode de travail] ça n'a pas grand chose à voir
Ben, quand même un peu. Quand il y a un outil pour naviguer rapidement dans les classes, on a tendance à ne pas s'embêter à organiser les sources... et du coup un simple grep ne suffit pas, je suis bien d'accord. Tout est une question de méthode de travail, et il n'est pas simple de se séparer de la méthode de travail proposée (imposée?) par le Visual C++; personnellement, il m'a fallu un moment, mais je me sens bien mieux... plus libre.
[^] # Re: interet d'une IDE sous Linux
Posté par pas_moi . En réponse à la dépêche C++ Builder sous Linux : bientôt du neuf !. Évalué à 10.
Avec l'expérience, tu apprends à générer ce genre de fichier en quelques minutes, et de façon durable (ne pas avoir à tout revérifier à chaque fois). Un browser de méthodes/fonctions ne remplacera jamais une méthode de travail claire et rapidement compréhensible par d'autres, j'aurais même tendance à ajouter «au contraire»: quand je vois des projets développés sous Visual C++ avec un grand nombre de classes et juste 3 ou 4 fichiers source dans le projet, je me dis que si le développeur avait eu à rechercher les classes/méthodes à la main, il aurait pris l'habitude de mieux ranger son code...
Les interfaces de navigation dans le code facilitent le travail mais ne le rendent pas plus propre, au contraire (cette fois-ci, je n'hésite pas à le dire).
[^] # Re: c++ sous linux ? enfin depuis le temps qu'on l'attendait
Posté par pas_moi . En réponse à la dépêche C++ Builder sous Linux : bientôt du neuf !. Évalué à 8.
et??? Moi j'ai déjà vu des momes qui croyaient au Père Noël...
Tous ceux qui critiquent vi sont ceux qui ne le connaissent pas assez ou qui croient que quand on a un outils il faut toujours s'en servir («quand le seul outils que l'on possède est un marteau, on a tendance à voir les problèmes comme des clous» disait je ne sais qui). Personnellement, je développe sous XEmacs, et j'édite les fichiers de conf (ou les petites modifs dans les sources) à l'aide de vim... J'ai une connaissance assez médiocre des techniques de la mort de chacun de ces outils, mais je sais à peu près quand utiliser l'un ou l'autre.
[^] # Re: interet d'une IDE sous Linux
Posté par pas_moi . En réponse à la dépêche C++ Builder sous Linux : bientôt du neuf !. Évalué à 10.
Linux ne manque pas d'IDE, mais il n'y a pas d'IDE à la Visual C++ sous Linux (et encore, KDevelopp à l'air de s'en approcher un peu trop :-) Pour débuter, on a besoin d'avoir des règles de développement, des méthodes de travail, et le Visual C++ force à en avoir certaines, mais avec l'expérience, on est bien content de pouvoir se faire son propre environnement à base de makefiles, gcc, gdb (parfois ddd, mais pas trop quand même), autoconf, dpkg-buildpackage...
Comparer l'environnement Visual C++ à vi, ça c'est un joli troll, presque autant que de comparer XEmacs (notez le X) à vi...
[^] # Re: argument ou pas
Posté par pas_moi . En réponse à la dépêche Opera 6 TP3. Évalué à 5.
Quand quelqu'un me dit qu'il n'aime pas Windows parce que c'est payant, je le remets à sa place: Windows n'est pas bien parce que le niveau de sécurité/stabilité de ce produit est lamentable (et donc ne devrait pas être vendu, mais l'argument n'est pas là). Moi aussi je trouve qu'Opera est trop cher pour ce qu'il est stable, n'empèche que sa version gratuite avec bandeau est bien rapide et pas trop buggée quand je la compare à Mozilla (attention, j'utilise aussi Mozilla que je trouve suffisament stable face à un IE qui n'arrive pas à respecter la moitié des normes W3C correctement). Personne n'oblige dva (ou n'importe quel autre utilisateur privé de liberté) à utiliser Opera mais il a tout à fait le droit de dire qu'il regrette que la version gratuite ait un bandeau, ce qui n'en fait pas un argument pour dire si Opera est bien ou pas.
Comme d'hab, il semblerait que l'on soit d'accord sur le fond, mais pas sur la forme, et je suis très chiant sur la forme: les meilleurs trolls sont ceux qui jouent sur la forme (un troll n'est pas forcément un mensonge, je le rappelle). Quand Microsoft parle de la GPL en tant que license virale, je trouve les termes employés aussi bien choisis que quand un autre dit que Windows est de la merde: c'est vrai, mais il y a quand même des façons un peu moins lourdes de le dire (là, je rentre dans le politiquement correct, faut que je fasse gaffe).
[^] # Re: Comment ça on est d'accord??
Posté par pas_moi . En réponse à la dépêche Scan par témoin. Évalué à 3.
> bien ils n'avaient pas coché la case
> 'antispoofing' sur toutes les interfaces
J'espère que tu voulais dire interfaces externes ;-D Car si tu antispoof les internes (et bloque 192.168.X.X et 10.X.X.X) tu n'es pas bien...
C'est ici que commencent tes posts insignifiants? Parce que pour quelqu'un qui s'y connaît, il s'agit quand même d'une belle bêtise.
Le seul commentaire de toi que je vois avant celui-là dans ce thread, c'est le commentaire où tu donnes quelques URLs (sûrement très intéressantes, mais ne t'obligeant pas à raconter et soutenir n'importe quoi par la suite).
Sur la "lan", ce n'est pas de l'anti spoofing de se réduire aux adresses locales, en effet n'importe qui peut changer très facilement d'adresse locale (excepté si on teste les adresses mac mais rarement exploitable).
Là, c'est sûr, tu venais de fumer la moquette avant d'écrire cette phrase... Empêcher un paquet dont l'adresse source n'appartient pas au lan1 de passer du lan1 au lanX, ce n'est pas de l'antispoofing d'après toi?
Le reste du commentaire est navrant de bêtise et je ne préfère pas en parler. Si c'est un troll que tu voulais faire, je ne le trouve pas des plus réussi au niveau finesse (même s'il a quand même eu une belle efficacité).
Ensuite arrive le coup du firewall connecté à un seul réseau... bon, d'accord, tout le monde avait compris que tu voulais dire un seul réseau privé, mais ce serait quand même bien de prendre le temps de se relire. Toujours est-il que j'ai préféré te faire préciser la question plutôt que de répondre à ce qui me semblait assez trivial: l'explication reste valable si l'on retire une des pates au firewall ou qu'on en rajoute une centaine.
mes posts précédents montrent, il me semble que j'y connais quelque chose
Ben, désolé, mais sur ce thread, pas trop...
Cela n'aurait pas du produire de réaction
Tu peux préciser pourquoi? j'ai du mal à suivre: si tu fais des trolls dans le but de ne pas avoir de réaction, pourquoi donc alors? et si tu étais vraiment sérieux quand tu as posté tes bêtises, penses-tu vraiment que ça n'aurait pas du entrainer de correction?
Bon, on va arrêter de jouer parce que tu t'enfonces de plus en plus... je vais aller voir ce que tu as raconté sur les clients ssh (il paraît qu'il faut un serveur X pour faire du X11 forwarding :-)
[^] # Re: Comment ça on est d'accord??
Posté par pas_moi . En réponse à la dépêche Scan par témoin. Évalué à 3.
Tout le monde dit des bêtises de temps à autre, soit parce que ses idées sont mal écrites, soit parce que le sujet n'est pas maîtrisé dans son ensemble, soit parce que ce sont des bêtises tout court. Il faut savoir admettre quand on dit une bêtise et avoir le courage de dire pourquoi.
Dans ton cas, tu as tellement voulu défendre tes idées face à des arguments que tu n'as même pas cherché à nier que ça en devient ridicule. Les gens ont de la patience, mais faudrait voir à ne pas en abuser non plus, et même si tu n'insultes personnes avec tes posts à deux cents, faut quand même avouer que tu commences à nous les briser.
Ca m'embête d'en arriver à de telles grossièretés, mais je n'aime pas que l'on se foute de la gueule de ceux qui prennent le temps d'expliquer.
[^] # Re: argument ou pas
Posté par pas_moi . En réponse à la dépêche Opera 6 TP3. Évalué à 7.
Si pour toi le premier point est un argument, il faut me dire pour ou contre quoi: contre les logiciels commerciaux? contre les logiciels avec commerciaux qui ont une version gratuite? contre les logiciels gratuits qui ont des banières (sur mon écran, elle fait 10cm, pas 3km)? contre les logiciels payants?
On peut parler des logiciels commerciaux sans dire "ce truc honteusement payant avec ses hectares de publicité", tout comme il est possible de parler de la GPL sans dire "cette mauvaise license à tendances virales".
je ne comprend pas ton opposition entre avis et argument
Hein? J'ai opposé avis et argument? J'ai rapproché l'avis sans argument d'une personne et la non présence d'arguments dans la réponse à cet avis, ce qui est loin d'être la même chose.
Lorsqu'on a un avis, on le justifie en argumentant, c'est ça le principe, non ?
Tout à fait. Et tout ce que j'ai demandé, ce sont des arguments expliquant pourquoi dva n'aime pas Opera.
[^] # Re: Comment ça on est d'accord??
Posté par pas_moi . En réponse à la dépêche Scan par témoin. Évalué à 4.
La réponse reste la même: le paquet doit être refusé. Le firewall ne doit pas accepter en entrée un paquet n'ayant rien à faire sur l'interface qui le reçoit: l'interface lan0 refuse en entrée tout ce qui ne vient pas de 192.168.1.xxx tout comme l'interface wan0 refuse en entrée tout ce qui ne provient pas d'une IP routable sur internet.
[^] # Comment ça on est d'accord??
Posté par pas_moi . En réponse à la dépêche Scan par témoin. Évalué à 4.