reno a écrit 3881 commentaires

> Que c'est des vieux dino :)

La d'accord, s'ils n'ont pas remarqué que CISC ou pas les x86 avaient un rapport performance/prix enfonçant les autres CPU, c'est qu'ils vivent un peu trop dans leur tour d'ivoire..

Plus grand chose de RISC dans un PPC? Tu as fumé la moquette?
Tu as cité une longueur du mot d'instruction fixe, et:
- un grand nombre de registres.
- une architecture load/store.
- un jeu d'instruction assez regulier (pas trop de spécialisation des registres par exemple).
Ca fait quand même pas mal de "caractéristiques RISC" qui sont supportés par le PPC!

Euh, il y a quand même des habitudes sur les numéros de versions: 0.xy --> beta, x.yz: x, numéro de "compatibilité", etc..
Certains softs ne respectent pas ces "conventions" forcément cela induit en erreur ceux qui ne regardent pas plus loin, tu peux dire que ce sont des "crétins" mais je trouve que les programmeurs n'aident pas non plus..
Il y a plus interressant que d'être "créatif" sur les numéros de version: si je me souviens bien, il y en a même qui ont utilisé des numéros de version négatif, bof, bof..

> A part ca, Gnome est quand meme l'environnement par defaut sur Fedora/RedHat (qui reste la distribution la plus repandue), Ubuntu...

A ce sujet la: au boulot on utilise RedHat Enterprise 3, bien que Gnome soit le défaut, en regardant les utilisateurs, je pense que les 3/4 utilisent KDE..

J'ignore à quoi cela est du, mais c'est le cas..

Et pourtant, à mon avis RedHat ai fait un boulot de cochon dans leur façon d'installer KDE: ne pas fournir ksnapshot par défaut par exemple (ok TheGimp permet de faire des captures d'écrans, mais 1) il faut le savoir 2) c'est un poil lourd à démarrer!)..

Ceci dit, en tout dans RH3, je trouve que le desktop est assez mal fichu: de temps à autres je perds mes icones (peut-etre un effet de bord d'avoir le /home montés par NFS? Quand je kill X, je les récupère pour 15j environ), l'impression sous Linux est encore mal fichu (on avait une version de mozilla utilisant XPrint aui s'est mis à ne plus marcher on ignore pourquoi, il a fallu upgrader mozilla pour pouvoir de nouveau imprimer), le petit bouton de mise à jour et les économiseurs d'écrans qui bouffent 100% du CPU (voire pour l'économiseur d'écran plante la machine)..

J'ignore si RHE4 est mieux: un collégue a downloadé l'ISO hier et il lui a fallu 2h cette après-midi pour installer les patches (heureusement qu'on a une connexion rapide au boulot!) puis au reboot, le démarrage s'arrete sur grub, donc je n'ai pas pu y jeter un coup d'oeil.

Je ne connais pas Unbuntu, il a refusé de démarrer quand j'ai essayé de l'installer chez moi.

Ce sont des petits trucs, mais ça fait vraiment 'mal fini'.. Je ne dis pas que Windows est mieux, mais pour gagner des parts de marché par rapport à un monopole, il faut être meilleur!

Ceci dit dans le cas présent, c'est un peu logique que Linus, travaillant aux US, respecte la loi du pays dans lequel il est..

> Tu peux declarer ta variable au debut de la fonction et l'initialiser ou tu en as besoin. Il n'y a pas de probleme.

Bien sur, mais la variable elle a quelle valeur entre le moment ou tu l'as déclaré et au moment ou tu l'initialise?

Si par erreur tu lis cette variable avant de la definir reellement, le resultat est un bug aléatoire: suivant les exécutions ta variable non-initialisée peut avoir des valeurs différentes..

Les bugs aléatoire, non reproductible sont particulièrement "interressant" quand on cherche a debugger..

C'est plus propre de déclarer et d'initialiser la variable à l'endroit ou tu l'utilise..
Ce qui est possible aussi en C99.

Certes la liste des variables locales dans une fonction devient plus difficile a obtenir, mais ce n'est pas une grosse perte.

Pas d'accord et je ne dois pas être le seul à apprécier de pouvoir déclarer une variable quand je veux: C++ basé sur le C l'a ajouté et cela a été ajouté dans le C aussi en 99!

Imagines que tu ai une fonction ou tu n'utilises une variable que dans une partie de la fonction, si c'est à la fin, il va falloir faire des aller-retour dans ta fonction pour voir comment elle est initialisée pour être sûr que cette partie de la fonction est correcte: super pour la lisibilité les aller-retour.

Certes les fonctions sont censée être courte, mais bon celui qui n'a jamais codé une fonction qui prend deux écrans de haut me jette la première pierre ;-)

Pas d'accord et je ne dois pas être le seul à apprécier de pouvoir déclarer une variable quand je veux: C++ basé sur le C l'a ajouté et cela a été ajouté dans le C aussi en 99!

Imagines que tu ai une fonction ou tu n'utilises une variable que dans une partie de la fonction, si c'est à la fin, il va falloir faire des aller-retour dans ta fonction pour voir comment elle est initialisée pour être sûr que cette partie de la fonction est correcte: super pour la lisibilité les aller-retour.

Certes les fonctions sont censée être courte, mais bon celui qui n'a jamais codé une fonction qui prend deux écrans de haut me jette la première pierre ;-)

Je ne dis pas rester sur les languages existant, mais quand on crée un language, pour certains élément se baser sur C plutôt que sur Pascal (par exemple) me paraît une bonne idée étant donnée le nombre d'utilisateurs respectif de chaque langage..

Par exemple, utiliser CHARACTER comme nom de type à la place de char, je ne suis pas sûr que ce soit une bonne idée..

Quand il y a ammélioration, c'est sûr qu'il ne faut pas hésiter, mais la ou cela apporte peu d'intéret autant garder l'existant.

Ce sont des petits détails, mais ça compte pour "attenuer" la transition..

Oui, mais d'un autre coté dans la vrai vie, on a plus souvent a écrire des GUI que des compilos.
Et là, l'intéret des language fonctionnels..
[ oui, je sais, Ocaml est soi-disant un language multi-paradigme, et la marmote.. ]

Et il faut que ce soit dans un language répandus pour être maintenable en équipe..

Faut arréter de croire que ce qui est valable à l'école est valable dans la "vraie vie"..
Bonne chance pour convaincre ton patron d'utiliser OCaml plutôt que C, C++, Java quand tu es le seul de l'équipe à connaitre!
Si tu code un compilo, tu as probablement un bon argument (et encore!), mais à part ça..

Je viens de lire la spec de Lissac (évoqué plus haut), et j'étais mort de rire:une syntaxe, euh comment dire, pas terrible..
Par exemple un retour au déclaration de variables uniquement au début d'une fonction, pas au milieu; etc..

J'imagine un gars programmant en Python ou Ruby auquel on dit de programmer en Lissac, il doit avoir envie de se cogner la tête contre les murs assez rapidement..

Note que dans le bouquin en Français que j'ai lu pour essayer d'apprendre l'OCaml (sans y arriver), le style de programmation fonctionnel est largement mis en avant par rapport au style impératif, donc c'est un peu normal qu'OCaml soit perçu comme un language fonctionnel.

Oui, enfin ceux qui ont appris par eux même avant ont probablement appris un language impératif avant d'aller en fac..

En prépas, on utilisait le Pascal et j'ai commencé par le BASIC.

Maintenant ce serait plutôt le C, C++, Java, Shell ou Perl voire Ruby ou Python pour débuter.. tous des languages impératifs.

Euh, la puissance et la performance ne sont pas les seuls critères pour choisir un language: la lisibilité est mon critère favori.

Et là, Ruby enfonce totalement Ocaml auquel je trouve une syntaxe pas terrible..

Et bien c'est comme tout dans le libre, si cela n'interresse pas des developpeurs, cela ne va pas se faire tout seul..

J'ai déja écouté et curieusement celle-ci je n'aime pas..

Je dis curieusement car toutes les versions précédentes m'ont toujours bluffé par leur qualité.. Je les ai même sur mon baladeur MP3!

Pas totalement d'accord: Apple respecte la lettre de la LGPL et publie toutes les modifications apportées, KHTML pourrait être en GPL, cela ne changerait rien!

Par contre Apple ne respecte pas l'esprit GPL/LGPL en faisant tres peu d'effort pour intégrer leurs modifications dans le projet originel, bref un fork comme tu dis.

Certes les GPL/LGPL apportent la liberté de forker, liberté tres importantes et utile si le développeur original ne bosse plus dessus ou si on est en désaccord avec lui, mais forker pour forker comme Apple a fait, c'est assez méprisable..

Bah, Apple a fait souvent des bétises de ce type: un exemple au lieu d'utiliser OpenGL comme librairie graphique, ils ont utilisé leur propre API 3D, que personne n'a utilisé bien sûr: ils n'ont pas le pouvoir de Microsoft!
Résultat, ils ont du l'abandonner, en la remplaçant (finalement) par OpenGL, OpenGL qui entre temps s'est bien affaibli..
Si Apple avait utilisé OpenGL dès le départ, il est envisageable qu'OpenGL soit beaucoup plus utilisé actuellement [ bon ok, vous me direz avec des si.., c'est juste un exemple d'une des c*** d'Apple].

La je pense qu'Apple sous-estime le besoin de coopérer sainement avec des developpeurs du libres: apres un coup comme ça, je pense qu'il y a assez peu de developpeur de KDE qui seraient interressé par porter KOffice sur MacOSX, par exemple..

Et git apparemment est très rapide pour faire des merges d'arbre..

Par contre, là ou je suis surpris c'est que le merge de fichier n'a pas l'air d'être le problème numéro 1 de Linus..
Pourtant pour avoir joué au "mergeur" sur du CVS, c'est ch...^W pénible, et apparemment BK était assez bon sur ce sujet.

Ceci dit, je ne vois pas comment BK pouvait être meilleur que le classique 3-way merge, mais je doit manquer d'imagination!

PS: Je me demande si Mercurial a une chance contre git?

> Et puis question "comparaison avec windows" c'est totalement subjectif.

Pas vraiment, Windows, BeOS sont (enfin étaient pour BeOS) des OS génériques, avec les mêmes fonctionnalités en tant que desktop, c'est toi qui utilise AmigaOS, Win2k sur XBox comme point de comparaison invalide.

Ta conf n'est pas comparable avec Windows ou BeOS donc effectivement la comparaison ne veut rien dire.
Ceci dit, 30s au demarrage, c'est deja plus que BeOS sur un Celeron 333 donc bien plus ancien que ton celeron 1,4 GHz..

Je considére que le desktop de BeOS est equivalent a KDE ou Gnome..

C'est sur lancer un X pur est beaucoup plus rapide, mais a ce moment la, on ne mesure pas vraiment un 'progres'.

> arriver sous gdm en moins de 13s.

C'est bien mais c'est quand meme une regression, j'imagine que la machine est bien superieure a un Celeron 333 avec 128Mo de RAM..

Et aussi je pense que quand on arrive sous gdm, on arrive a la fenetre demandant le login, apres, il y a le demarrage de Gnome/KDE a proprement parler.

Hors sous BeOS, les 14s sur Celeron 333 incluait le temps de demarrage du desktop!
Donc pour comparer des choses comparables, il faut chronometrer jusqu'a avoir la main sur le desktop en passant gdm/kdm/.. en auto-login par exemple, avec un desktop comparable a celui de BeOS: KDE ou Gnome par exemple.

Oui, enfin pour les temps de démarrage, sous BeOS le boot durait moins de 15s et sans tricher comme WindowsXP qui fait apparaitre le desktop avant qu'il soit utilisable..

WindowsXP boote plus lentement sur un Athlon64 3200+ que le faisait BeOS sur un Celeron333, et je ne parle pas de Linux qui est pire (je parle du boot jusqu'au desktop, cela inclut le temps de démarrage du kernel et de KDE avec autologin, depuis Grub jusqu'a pouvoir démarrer un kwrite: je n'ai pas chronométré mais c'est long!).

Je trouve les applications sous WindowsXP ou sous Linux moins 'réactive' que le peu qu'il y avait sous BeOS donc sur certains points, le confort d'utilisation a *régressé*.

> L'activité autour de GIT est très intense

Super, mais pendant que Linus bosse sur git, il ne bosse pas sur le kernel..

> 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..