> Si ces 2 langages étaient tellement semblables, l'un des deux n'existerait surement pas/plus.
Ah? Alors pourquoi existe-t'il des dizaines de variantes de Lisp? de language fonctionnels? de language au-dessus de Java (je connais moins la: groovy, pyke, il me semble)?
Python était légèrement moins OO que Ruby, mais il a rattrapé son "retard": c'est amusant c'est que les discussions entre Pythoniste et Rubyiste, ça ressemble à ça: "il est pas mal votre language, mais il n'a pas la feature XXX", les tenants de l'autre language répondant, "tu retardes, ça a été incorporté en version x.y"..
Bref honnetement blanc bonnet et bonnet blanc, les deux seules grosses différences: le self très laid de python (mais qui permet de mapper élégamment une fonction sur une liste), et la gestion des espaces qui a ses farouches supporters/détracteurs, ça ne fait pas lourd..
Certes mais pour reellement comprendre le sujet, il faut comprendre la notion de thread..
Concept plutot difficile a exprimer en une phrase.. et n'ayant pas de traduction correcte en Francais, donc la première chose a faire est d'ouvrir wikipedia et de regarder le chapitre sur thread, mais je ne pense pas que le sujet doit expliquer ce qu'est une thread..
Bof, c'est un outil pour développeur, si tu es un developpeur le vocabulaire utilisé est trés clair, si tu ne l'es pas, le sujet ne t'interresse pas, alors..
> On peut même dire que linuxthread est très peu utilisé maintenant.
Ahem, tu n'exagères pas un peu? Tu sais une majorité de système utilisé en prod sont en 2.4, de la même manière que le noyeau 2.2 a mis lentement a mourrir, le 2.4 va rester utiliser pendant très longtemps: même pour des nouveaux développement..
Je sais RedHat a backporté les NPTL sur 2.4, mais sur 2.4 les third parties utilisent les linuxthread, alors..
> Automatiquement par le hardware modulo memory manager quand même. Et quand le swap s'en mèle le modulo est pas négligeable.
Je ne vois pas le rapport..
Tu peux utiliser de la shared memory sur des systèmes sans swap et les threads utilisent de la même manière le gestionnaire de mémoire virtuelle que les processus alors..
Pour le besoin de synchronisation, il est a mon avis rigoureusement identique entre des processus communiquants par mémoire partagée et des threads..
Pour les "gros" scripts: rapidement les shell montrent leur limites et la Perl devient plus interressant (plus homogène, et plus performant).
Dans ce domaine, il rentre en concurrence avec Ruby et Python, mais étant plus ancien, plus de programmeurs connaissent Perl et la libraire CPAN est plus fournie.
Par contre, et la c'est mon avis personnel, Perl est tres "crade" comme language: les débutants font du code inmaintenable et les expérimentés se font plaisir en utilisant du code incompréhensible , une des conséquence de la philosophie TMWTDI..
(ma vie) appelé au secours pour la reprise d'un script (le repreneur ayant jeté l'éponge), il m'a fallu 1/2h de recherches pour remplacer *2 lignes* imbitables par 2 lignes qu'un débutant en Perl peut comprendre, 15min par ligne, ce n'est pas très rentable! (/ma vie), Ruby ou Python sont tous les deux bien plus propre..
Le seul problème avec Ruby et Python, c'est qu'ils sont tellement semblables l'un à l'autre, qu'il est très difficile de choisir entre les deux! Petite préférence personelle pour Ruby quand même..
Un contre exemple, Word me fait criser avec sa sélection "intelligente": tu cliques a un endroit pour placer le curseur, tu shift+clique a un autre endroit pour selectionner le texte entre les deux et ce p***** de Word change la sélection tout seul: en général si j'ai cliqué au mileu d'un mot, il me sélectionne tout le mot par exemple..
Ca m'énerve les logiciels qui se croient plus malin que les utilisateurs..
Personellement je trouve que le| petit cheval blanc devrait donner le|petit cheval blanc: utile pour effacer plusieurs espace d'un seul coup par exemple, donc ni l'algo de Word ni celui d'OOo ne me paraissent terrible (bien que celui de Word soit meilleur la)
Oui, enfin survoler pas trop vite quand même: le petit jeune prestataire pour ma boite s'est trompé dans des histoires d'alignements mémoire, ne vérifie pas systèmatiquement les codes retour des fonctions de libraire, utilise sprintf plutôt que snprintf, etc..
Survoler un language, c'est bien, je l'ai fait aussi (Lisp, Prolog) à l'époque mais il vaut quand même se batir une "culture" sur un language utilisé: je n'ai jamais utilisé ni Lisp, ni Prolog, et je ne pense pas jamais les utiliser alors à part savoir qu'ils existent bof..
Pour ce qui est d'écrire des interpréteurs en C, je l'ai fait aussi, pourquoi?
Je n'avais pas le choix du language! Donc les languages exotiques, c'est bien, mais ça reste peu connu et donc peu utilisable.
Dans mon projet actuel, j'ai bien essayé de vendre Ruby, mais trop peu répandu --> shell + C.
Maintenant quand tu arrives dans une boite et que tu n'es pas capable de faire du C ou du C++ propre car tu ne l'as pas suffisamment utilisé, cela ne va pas être très bien vu..
OCaml a aussi un probleme de syntaxe: par défaut sa syntaxe est assez pourri..
J'avais essayé d'apprendre ce language, mais j'ai abandonné car Ocaml c'est quand même assez bof-bof au niveau syntaxe.
Je ne dois pas être le seul a leur avoir fait la remarque, apparemment il y a une syntaxe "alternative" possible, mais j'ai découvert Ruby entre temps et je n'ai donc pas regarder à quoi ça correspond..
Euh, et toi tu n'est pas arrogant? Relis un peu ton poste.
D'abord, chaque projet a ses spécificité, ensuite KDE est en train de migrer de CVS a Subversion, donc apparemment ils ne doivent pas être si satisfait que ça de CVS..
Quel était l'état de Subversion, il y a 3 ans quand Linus est passé a bitkeeper?
Il était peut-etre possible de changer le style de developpement en gardant CVS, mais avec des si on ne va pas bien loin..
Euh, il y a une grosse difference entre MSN Messenger, IE, et bitkeeper: les 2 premiers ne sont *PAS* gratuit, seulement tu les payes avec le prix de ton OS: Microsoft a utilisé les bénéfices fait en vendant Office, Windows pour les developper..
Bitkeeper, pour la version gratuite lui ne dependait en rien de l'achat d'autre chose.
Ceci dit, "punir" une communauté parce qu'un de ses membres fait quelque-chose de "répréhensible" (du point de vue de Larry Mc Voy), sans commentaire.
Enfin, Bitkeeper aura quand même eu le gros avantage de faire avancer Linux plus rapidement durant une certaine période, par contre la migration des données ne devrait pas être drole..
Ce qui est amusant, c'est qu'au boulot je travaille sur un rack ATCA piloté par IPMI (telecom) et j'avoue ne rien avoir compris au texte du dessus..
Dans les racks ATCA, il est faux que les controleurs (shelf manager) utilisent un slot dans un rack: soit ils sont intégrés sur une carte (les swiches par exemple) soit ils sont planqués en dessous du rack par exemple.
Mais peut-etre que l'article du dessus parlent de PC empilables (stackables) plutot que de serveur de lames?
Moui, enfin dans le cas présent le fait que le TLB ne soit qu'une partie du MMU n'a rien avoir avec la choucroute..
Comme dit plus haut une gestion par le noyeau de taille de page variable permettrait une meilleure utilisation du TLB, qui en général n'est pas bien gros..
J'ajouterai que le noyeau gère des listes qui décrivent l'utilisation des pages, avec les taille mémoires actuelles et des pages de 4k, la taille de ces structures est assez importantes..
Une gestion des pages avec une taille variable permettrait probablement de réduire la taille occupées par ces listes.
Le gain en performance se faisant problablement sentir sur les configurations avec beaucoup de mémoire.
Ma vie: au boulot on est passé d'un projet Sun à un projet sur Linux, étant admin, j'ai bien senti la différence: Linux fait un peu amateur à coté de Solaris: doc plus foulli, stabilité inférieure (je perds les icones de mon KDE environ tous les 15j, bah je m'en passe, mais ça fait désordre, j'ignore si c'est la faute de RedHat)..
Maintenant coté Solaris, il y a des choix qui sont politiques et indéfendables techniquement: utilisation de CDE (stable certe, mais qui est une grosse m...: c'est le seul soft ou certaines appli ne marchent pas en export DISPLAY!!!), remplacement d'outils utile par des javateries lentes et nettement moins utilisables (ce qui m'a conduit a apprendre les lignes de commandes équivalentes pour éviter d'utiliser cette saleté de console java).
Bref, grosso-modo ça se vaut, le coté le plus génant dans Linux, c'est la doc: c'est un gros bordel entre les docs en info qui sont franchement mauvaise (1 paragraphe par page en moyenne, outil de lecture pourri..) et des docs parfois inexistante (2 journée entieres passée sur le web pour trouver comment faire pour faire des accents avec un clavier QWERTY sans l'histoire de changement de clavier), c'est le plus gros manque: Solaris est livré avec des classeurs entiers de doc, un peu trop verbeuse a mon gout, mais nettement mieux quand même.
Ceci dit comme tous le monde le sait la doc de Linux est quand meme supèrieure a celle de Windows qui prend l'utilisateur pour un imbècile et n'apporte rien..
Pas tres realiste ce que tu dis, la réalité est que Windows est là et que si tu veux ajouter du Linux dans un environement Windows, tu dois t'intégrer dans l'existant en minimisant le changement.
Bof et les cartes videos pour PC portables?
Si elles sont faibles consommations pour les PC portables, ça doit aussi marcher pour l'embarqué..
En plus de par le principe même un FPGA est plus gourmand que le circuit intégré correspondant, bin oui il faut plus de transistor pour pouvoir le reprogrammer..
[^] # Re: GIT, Cogito, WIT Re: C'est fait, c'est fait ...
Posté par reno . En réponse à la dépêche M. Tridgell publie son client libre pour Bitkeeper. Évalué à 1.
Super, mais pendant que Linus bosse sur git, il ne bosse pas sur le kernel..
[^] # Re: Sacré langage!
Posté par reno . En réponse à la dépêche Journées Perl 2005. Évalué à 2.
Ah? Alors pourquoi existe-t'il des dizaines de variantes de Lisp? de language fonctionnels? de language au-dessus de Java (je connais moins la: groovy, pyke, il me semble)?
Python était légèrement moins OO que Ruby, mais il a rattrapé son "retard": c'est amusant c'est que les discussions entre Pythoniste et Rubyiste, ça ressemble à ça: "il est pas mal votre language, mais il n'a pas la feature XXX", les tenants de l'autre language répondant, "tu retardes, ça a été incorporté en version x.y"..
Bref honnetement blanc bonnet et bonnet blanc, les deux seules grosses différences: le self très laid de python (mais qui permet de mapper élégamment une fonction sur une liste), et la gestion des espaces qui a ses farouches supporters/détracteurs, ça ne fait pas lourd..
[^] # Re: Je la pose, ma question ?
Posté par reno . En réponse à la dépêche PTT : un outil de trace pour la NPTL. Évalué à 2.
Concept plutot difficile a exprimer en une phrase.. et n'ayant pas de traduction correcte en Francais, donc la première chose a faire est d'ouvrir wikipedia et de regarder le chapitre sur thread, mais je ne pense pas que le sujet doit expliquer ce qu'est une thread..
[^] # Re: Je la pose, ma question ?
Posté par reno . En réponse à la dépêche PTT : un outil de trace pour la NPTL. Évalué à 2.
[^] # Re: NPTL
Posté par reno . En réponse à la dépêche PTT : un outil de trace pour la NPTL. Évalué à 2.
Ahem, tu n'exagères pas un peu? Tu sais une majorité de système utilisé en prod sont en 2.4, de la même manière que le noyeau 2.2 a mis lentement a mourrir, le 2.4 va rester utiliser pendant très longtemps: même pour des nouveaux développement..
Je sais RedHat a backporté les NPTL sur 2.4, mais sur 2.4 les third parties utilisent les linuxthread, alors..
[^] # Re: vs POSIX shared memory
Posté par reno . En réponse à la dépêche PTT : un outil de trace pour la NPTL. Évalué à 3.
Je ne vois pas le rapport..
Tu peux utiliser de la shared memory sur des systèmes sans swap et les threads utilisent de la même manière le gestionnaire de mémoire virtuelle que les processus alors..
Pour le besoin de synchronisation, il est a mon avis rigoureusement identique entre des processus communiquants par mémoire partagée et des threads..
[^] # Re: L'info sur kerneltrap
Posté par reno . En réponse à la dépêche Linus développe un remplaçant original à BitKeeper. Évalué à 3.
Tu en sais en Français, il n'y a pas l'ambiguité free/Free de l'Anglais, autant en profiter!
[^] # Re: Sacré langage!
Posté par reno . En réponse à la dépêche Journées Perl 2005. Évalué à 3.
Dans ce domaine, il rentre en concurrence avec Ruby et Python, mais étant plus ancien, plus de programmeurs connaissent Perl et la libraire CPAN est plus fournie.
Par contre, et la c'est mon avis personnel, Perl est tres "crade" comme language: les débutants font du code inmaintenable et les expérimentés se font plaisir en utilisant du code incompréhensible , une des conséquence de la philosophie TMWTDI..
(ma vie) appelé au secours pour la reprise d'un script (le repreneur ayant jeté l'éponge), il m'a fallu 1/2h de recherches pour remplacer *2 lignes* imbitables par 2 lignes qu'un débutant en Perl peut comprendre, 15min par ligne, ce n'est pas très rentable! (/ma vie), Ruby ou Python sont tous les deux bien plus propre..
Le seul problème avec Ruby et Python, c'est qu'ils sont tellement semblables l'un à l'autre, qu'il est très difficile de choisir entre les deux! Petite préférence personelle pour Ruby quand même..
[^] # Re: Mon expérience avec {MS|Open}Office
Posté par reno . En réponse à la dépêche Linux pour les débutants c'est facile !. Évalué à 5.
Ca m'énerve les logiciels qui se croient plus malin que les utilisateurs..
Personellement je trouve que le| petit cheval blanc devrait donner le|petit cheval blanc: utile pour effacer plusieurs espace d'un seul coup par exemple, donc ni l'algo de Word ni celui d'OOo ne me paraissent terrible (bien que celui de Word soit meilleur la)
[^] # Re: Pérénité
Posté par reno . En réponse à la dépêche Présentation d'OCaml à Rennes le jeudi 7 avril, 20h, MCE, 48 bd Magenta. Évalué à 1.
Survoler un language, c'est bien, je l'ai fait aussi (Lisp, Prolog) à l'époque mais il vaut quand même se batir une "culture" sur un language utilisé: je n'ai jamais utilisé ni Lisp, ni Prolog, et je ne pense pas jamais les utiliser alors à part savoir qu'ils existent bof..
Pour ce qui est d'écrire des interpréteurs en C, je l'ai fait aussi, pourquoi?
Je n'avais pas le choix du language! Donc les languages exotiques, c'est bien, mais ça reste peu connu et donc peu utilisable.
Dans mon projet actuel, j'ai bien essayé de vendre Ruby, mais trop peu répandu --> shell + C.
[^] # Re: Pérénité
Posté par reno . En réponse à la dépêche Présentation d'OCaml à Rennes le jeudi 7 avril, 20h, MCE, 48 bd Magenta. Évalué à 2.
OCaml a aussi un probleme de syntaxe: par défaut sa syntaxe est assez pourri..
J'avais essayé d'apprendre ce language, mais j'ai abandonné car Ocaml c'est quand même assez bof-bof au niveau syntaxe.
Je ne dois pas être le seul a leur avoir fait la remarque, apparemment il y a une syntaxe "alternative" possible, mais j'ai découvert Ruby entre temps et je n'ai donc pas regarder à quoi ça correspond..
[^] # Re: bel exemple...
Posté par reno . En réponse à la dépêche BitKeeper : plus de version gratuite. Évalué à 2.
D'abord, chaque projet a ses spécificité, ensuite KDE est en train de migrer de CVS a Subversion, donc apparemment ils ne doivent pas être si satisfait que ça de CVS..
Quel était l'état de Subversion, il y a 3 ans quand Linus est passé a bitkeeper?
Il était peut-etre possible de changer le style de developpement en gardant CVS, mais avec des si on ne va pas bien loin..
[^] # Re: Le paternalisme, c'est mal.
Posté par reno . En réponse à la dépêche BitKeeper : plus de version gratuite. Évalué à -1.
Bitkeeper, pour la version gratuite lui ne dependait en rien de l'achat d'autre chose.
Ceci dit, "punir" une communauté parce qu'un de ses membres fait quelque-chose de "répréhensible" (du point de vue de Larry Mc Voy), sans commentaire.
Enfin, Bitkeeper aura quand même eu le gros avantage de faire avancer Linux plus rapidement durant une certaine période, par contre la migration des données ne devrait pas être drole..
[^] # Re: Soyons clair
Posté par reno . En réponse à la dépêche SPIP 1.8 est sorti. Évalué à 8.
Ce qui est prècisement le cas ici, donc je ne vois pas en quoi c'est un problème.
# Rien compris..
Posté par reno . En réponse à la dépêche L'architecture OPMA de AMD est disponible. Évalué à 3.
Dans les racks ATCA, il est faux que les controleurs (shelf manager) utilisent un slot dans un rack: soit ils sont intégrés sur une carte (les swiches par exemple) soit ils sont planqués en dessous du rack par exemple.
Mais peut-etre que l'article du dessus parlent de PC empilables (stackables) plutot que de serveur de lames?
[^] # Re: Utilité de Mono
Posté par reno . En réponse à la dépêche Interview de Miguel de Icaza par O'reilly. Évalué à -2.
Les chercheurs de microsoft ont aussi produit BOB.. Donc ils font de la merde aussi, c'est un fait aussi.
La leçon est qu'il faut voir au cas par cas la production pas généraliser..
Ils font parfois du bon travail, parfois de la merde.
# Traduction?
Posté par reno . En réponse à la dépêche Un exposé sur la fibre optique à la maison le 24 mars 2005 à Rennes. Évalué à 2.
[^] # Re: Il manque
Posté par reno . En réponse à la dépêche Sortie du noyau 2.6.11. Évalué à 1.
Comme dit plus haut une gestion par le noyeau de taille de page variable permettrait une meilleure utilisation du TLB, qui en général n'est pas bien gros..
J'ajouterai que le noyeau gère des listes qui décrivent l'utilisation des pages, avec les taille mémoires actuelles et des pages de 4k, la taille de ces structures est assez importantes..
Une gestion des pages avec une taille variable permettrait probablement de réduire la taille occupées par ces listes.
Le gain en performance se faisant problablement sentir sur les configurations avec beaucoup de mémoire.
[^] # Re: De la criticité des bugs
Posté par reno . En réponse à la dépêche Démarche qualité et Logiciel Libre. Évalué à 3.
Alors dans le logiciel propriétaire, même quand on peut voter pour des bugs, cela n'est pas forcément mieux.
[^] # Re: ha ?!??
Posté par reno . En réponse à la dépêche Démarche qualité et Logiciel Libre. Évalué à 4.
Maintenant coté Solaris, il y a des choix qui sont politiques et indéfendables techniquement: utilisation de CDE (stable certe, mais qui est une grosse m...: c'est le seul soft ou certaines appli ne marchent pas en export DISPLAY!!!), remplacement d'outils utile par des javateries lentes et nettement moins utilisables (ce qui m'a conduit a apprendre les lignes de commandes équivalentes pour éviter d'utiliser cette saleté de console java).
Bref, grosso-modo ça se vaut, le coté le plus génant dans Linux, c'est la doc: c'est un gros bordel entre les docs en info qui sont franchement mauvaise (1 paragraphe par page en moyenne, outil de lecture pourri..) et des docs parfois inexistante (2 journée entieres passée sur le web pour trouver comment faire pour faire des accents avec un clavier QWERTY sans l'histoire de changement de clavier), c'est le plus gros manque: Solaris est livré avec des classeurs entiers de doc, un peu trop verbeuse a mon gout, mais nettement mieux quand même.
Ceci dit comme tous le monde le sait la doc de Linux est quand meme supèrieure a celle de Windows qui prend l'utilisateur pour un imbècile et n'apporte rien..
# "Personne préssé"
Posté par reno . En réponse à la dépêche L'envoi de courriers électroniques chiffrés sous KDE. Évalué à 0.
[^] # Re: Un article inquiétant
Posté par reno . En réponse à la dépêche Délégation de pouvoirs avec un contrôleur de domaine Samba. Évalué à 2.
D'ou les problemes de compatibilité..
[^] # Re: Sympa
Posté par reno . En réponse à la dépêche GCfilms : Logiciel de gestion de films. Évalué à 1.
Normalement un rpm conforme a la LSB doit pouvoir s'installer sur une majorité de distrib.
[^] # Re: sécurité des serveurs
Posté par reno . En réponse à la dépêche Hurd : nouvelle version de Debian GNU/Hurd et avancée du port sur L4. Évalué à 4.
Ca te fait une belle jambe si la faille vient d'une surcouche plutot que du noyau..
[^] # Re: Et l'image du libre?
Posté par reno . En réponse à la dépêche Interview de Timothy Miller, du projet Open Graphics. Évalué à 1.
Si elles sont faibles consommations pour les PC portables, ça doit aussi marcher pour l'embarqué..
En plus de par le principe même un FPGA est plus gourmand que le circuit intégré correspondant, bin oui il faut plus de transistor pour pouvoir le reprogrammer..