reno a écrit 3886 commentaires

Pour la première partie, pas d'accord mais bon "des gouts et des couleurs"..

> L'avenir des langages est pour moi vers des langages de spécifications en langages naturels.

Bof, on avait des langages de dev en 'language naturel' (COBOL) et on en est revenu.
Et remplacer des langages de dev, par des langage de spec n'apporte pas grand chose: au lieu d'avoir des erreurs de codage, on a des erreurs de spec, le gain n'est pas terrible..

>>
A première vue, du point de vue la syntaxe et du fait que tout à l'air objet pour Ruby et Lissac, Lissac me fait penser à Ruby
<<
Tu es allé cherché la ressemblance ou??

C'est amusant, cela m'a fait exactement l'effet opposé coté syntaxe: Ruby a une syntaxe riche destiné à simplifier la vie au programmeur et Lissac a une syntaxe destiné à simplifier la vie au compilateur.

>Le seul truc qu'on ne pourrait pas techniquement faire sans VM serait une exécution 'sandboxée'

Si on te prends à la lettre tu as raison bien sûr.
Mais des chercheurs pour Microsoft bossent sur un OS Singularity écrit en C# mais compilé "normalement" sans VM, les threads de l'OS partagent tous le même espace mémoire mais ils utilisent des preuves de programmes pour s'assurer que deux thread ne vont pas écrire ailleurs qu'elles en ont le droit, ce qui est une forme de 'bac à sable'.

Ceci dit, tout l'OS n'est pas prouvé bien sûr..

Un arbre, un tri, je cherche à me souvenir quand j'ai eu à m'intérresser à ça, ouhla ça fait loin..

Pour le tri, il y a des librairies qui font cela que l'implémentation soit récursive ou pas bof.

La plupart du temps quand on programme, cela tient plus de la recette de cuisine avec des bon vieux automates à état fini qu'aux algorithmes que tu as cité, donc la recursivité, à part dans les bouquins d'algo, bof!

> tu veux dire que tu n'as jamais accidentellement fait une affectation en lieu et place d'un test ?

Si, mais comme j'utilise gcc en -Wall, j'ai corrigé le probleme rapidement.

De plus c'est un probleme qui vient surtout des types en C: si les int et les bools étaient des types disjoints, dans la majorité des cas le compilateur se plaindrait si on faisait une affectation à la place d'un test. Il est vrai que cela pourrait toujours se produire c'est en faisant un test sur une variable booleenne..

Bof, si ceux qui avait fait un TP en language fonctionne avaient trouvés le language interressant, ils l'utiliseraient ensuite non?

Si tu juges l'avis des étudiants qui apprennent un language pas pertinent, il ne faut pas s'étonner que personne ne l'utilise..

Tu le pense peut-etre, mais vu le succes relatif des languages fonctionnel ton point de vue est minoritaire..

Oui enfin le passage de parametre par nom plutot que par position n'est pas une nouveauté: Ada, Python, etc..

Je suis d'accord que c'est plus lisible mais je n'aime pas non plus le reste de la syntaxe de Lisaac.

> Un bon point concernant la syntaxe, c'est l'adoption comme en Pascal par exemple, du ":=" pour l'affectation et non plus le "=" du C qui a forcément joué des tours à beaucoup d'entre nous.

Forcément? Tu prends ton cas pour une généralité!

Utiliser la syntaxe Pascal/Ada pour l'affectation plutot que celle du C me paraît assez absurde, le nombre de programmeurs Pascal/Ada se comptant sur les doigts d'une main..

Dans certains, la syntaxe du C a de clair inconvénient: la lecture des déclaration de variable en C est bien plus complexe que celle de Pascal, mais l'affectation ne fait pas partie de ces cas la..

> La qualité typographique de LyX / LaTeX est bien supérieure à ce que l'on peut obtenir avec OpenOffice ou KWord.

Bof, ça veut dire quoi "qualité typographique", j'ai vu plein de doc rédigé avec LateX et d'autre avec Word et je n'ai pas remarqué de différence: elle ne doit pas être bien flagrante, cette fameuse "qualité typographique".

> Un traitement de texte qui tenait la route pour les gros documents, c'est Framemaker

D'ailleurs KWord malgres son nom indique/indiquait bien que son inspiration vient de framemaker..

Merci, c'est soulant de faire "view source" pour récupérer l'URL..

> si une "petite" entreprise comme SCO attaque une grosse, comme IBM, le tribunal favorisera (au moins au début) le plaignant, histoire de lui laisser sa chance... (sinon, il se fait écraser direct !)

Si le plaignant peut montrer un préjudice réel, cela me semble normal, mais dans le cas de SCO, on attend toujours 3 ans après le début du procès..
Ce n'est pas sérieux de laisser trainer autant un procès frivole..

Je pense que dans le cas présent c'est "juriste d'IBM" = "font peur": ils ont leur réputation..

Ce qui est incroyable quand même c'est l'argent dépensé dans un procés qui me parait fantaisiste, j'ai l'impression que les tribunaux américains favorisent le plaignant de manière assez absurde (SCO a changé le motif de la plainte en cours de route je crois, incroyable..).

> en SVT (je sens que ça va jaser)

Euh, il faudrait déja qu'on sache ce que SVT veut dire..

Science de la Vie Terrestre? Les acronymes dans l'éducation, cela change toutes les 5 minutes..

>le nombre même de tests à faire pour démarrer le système est nettement plus conséquent.

Bof, si c'est vraiment ça la raison qui retarde le démmarrage pourquoi tester à *chaque* démmarrager??
On ne change pas de matériel touts le temps et il suffirait d'ajouter un outil pour voir les changements (quitte à rebooter si nécéssaire).

BeOS n'avait pas beaucoup de drivers, c'est vrai mais ce n'était quand même pas une configuration figée: c'etait plus un probleme de ressource qu'une volontée.

> Enfin, dans la philosphie de Unix/Linux, il n'est pas habituel de redémarrer son ordinateur

La philosophie dépend du besoin, pas de l'OS: ok on n'arrète pas les serveurs dans leur salle machine, mais dans mon studio mon ordinateur (pourtant très silencieux) est trop bruyant pour que je le laisse allumer la nuit si je veux dormir.

Et je me répète: BeOS faisait 14s *sans optimisation de l'utilisateur* et ce temps inclue le démmarrage du desktop (fonctionnel pas comme sous WindowsXP) alors que souvent sous Linux dans le temps de boot on ne compte pas le démmarrage de Gnome ou KDE, certes j'imagine qu'il y avait quelques fonctionnalité en moins dans BeOS (je ne me souviens plus trot), mais l'interface graphique en plus!

Pour ce qui est des serveurs présents par défaut, je pense (et j'espère ne pas me tromper) que ce n'est plus trop le cas sous Linux, d'un point de vue sécurité, c'est une très mauvaise idée!

>Maintenant, il reste à accélérer le lancement des interfaces graphiques

Pas tout à fait..

Ce que je trouve amusant dans la thread que tu as linké, c'est qu'il y a un utilisateur pour lequel pinit fait passér de 46s à 42s, et il trouve que c'est une indication comme quoi le système est bien optimisé.

Ca plus ta remarque, c'est plutôt amusant: BeOS sur une machine bien moins puissante que maintenant démmarait en 14s (du boot loader à l'interface graphique fonctionnelle et sans aucune optimisation de ma part).. Ce temps correspondrait sous Linux au boot du kernel *plus* le demarrage d'une interface graphique en "auto-login"!

Ce n'est pas prés d'arriver sous Linux, malheureusement..

Du "concret" qui reste quand meme bien abstrait car a priori les étudiants ne produiront jamais de CPU eux, mais étudier comment Sun le fait doit être tres interressant pour les étudiants, oui..

C'est bien ça le probleme d'ailleurs, le matériel sous Linux ce n'est pas un site bien foutu, mais beaucoup de site pas très bien fourni et souvent obsolète..

Une anecdote: je cherchais une carte SCSI pour Linux, je demander à mon service achat une carte, il me trouve une carte à 150 euros, je demande si elle est bien compatible Linux comme je l'avais demandé ils me disent qu'ils ne savent pas et qu'ils vont se renseigner et me proposent ensuite une carte qui coute 4 fois plus cher.

Trouvant la pilure un peu amère, je cherche à vérifier si la carte moins chere est compatible et abandonne au bout d'1h, ayant un stagiaire sous la main qui n'était pas très occupé je lui demande de vérifier si la carte moins cher n'est pas compatible Linux: ça lui a pris 2 jours!

Le cout de la recherche aurait normalement dépassé le cout de la carte!! Pas terrible comme situation..

Franchement ça fait un poil charlot les prix français "65 caméras pour 60 employés": j'imagine que le nombre de caméra dépend de la surface à couvrir pas du nombre d'employés..

Les prix des "pays bas" me paraissent beaucoup plus interressant: le ministre qui envoit au pay d'origine les informations des demandes d'asile ça c'est grave.

Merci pour l'info, je ne connaissais ClearType power toy, cela peut être utile dans un cas, il y avait des effets "colorés" quand j'ai activé ClearType, probablement parce que l'écran LCD devait être en BGR plutôt qu'en RGB, j'imagine que cet outils peut régler ce probleme.

Bien sur, les écrans LCD étaient dans leur résolutions native..

Bien sûr les 3 personnes utilisaient un écran LCD!

Et je ne suis pas convaincu qu'il s'agisse d'une résistance au changement: pour 2, c'était l'installation initiale d'un laptop, donc pas un changement dans leurs habitude..

> garbage collector (qui de facto utilise plus de mémoire (je rempli tant que j'ai de la place, je nétoi quand j'ai du temp ou plus de place) qu'un code C/C++ bien développé

Ta vision des GC est un peu limité, il existe des papiers sur des GC qui dialogueraient avec la VM pour nettoyer suivant les besoins: plus de GC qui perdent des perf en sous-utilisant la mémoire ou pire qui font swapper en utilisant trop de RAM.
Exemple: "Page-Level Cooperative Garbage Collection", maintenant j'ignores s'il existe des GC et des VM qui implémentent ça, je verrais bien ce genre de chose ajoutée à Linux par exemple.

Le probleme dans ce que tu dits pour le C/C++, c'est le "bien développé", un bon exemple ou le C/C++ échoue c'est Mozilla/Firefox qui a tendance a bouffer de la RAM sans jamais diminuer, franchement à partir d'un certain niveau de complexité ne pas faire de fuite mémoire en C/C++ est très dur..
Bien sûr avec un GC on remplace la fuite mémoire par la fuite d'objets si on ne fait pas attention, mais c'est quand même plus facile à gérer..

A partir de la, j'avoue avoir une tres mauvaise experience de Java (même Sun n'est pas fichu de faire des appli Java graphique "legere" cf les outils d'admin dans Solaris9..) ou .Net pour les GUI, mais est-ce du au GC ou aux machines virtuelles?

Difficile à dire, je n'ai jamais eu l'occasion de jouer avec des appli en language compilé avec GC..

Sauf que la LGPL est mal foutue..

Plutot que parler d'édition de liens, la LGPL devrait plutot parler d'interface publique à mon avis: toute modification sous l'interface publique devant être rendu publique, ce qui est fait au dessus n'étant pas restreint (enfin sauf bien sur que le code ne peut pas réutiliser l'interface publique en la modifiant, ce qui est une façon de faire une modification cachée).

J'ignore si c'est l'implémentation de Microsoft ou si c'est le concept en lui-même, mais j'ai aidé 3 personne a installer Windows et systèmatiquement quand je demandais aux utilisateurs s'ils préféraient avec ou sans cleartype, ils répondaient sans.

Bon 3 personne, c'est un échantillon assez faible, mais 3/3 contre..