TeXitoi a écrit 358 commentaires

int
rand4(void)
{
        int d;
        while ((d = dice()) > 4)
                ;
        return d;
}

Cette fonction fini presque surement en un temp infini.

Ba, quand même, en terme de périnité, c'est pas top : le jour où lighthouse dit «maintenant, c'est payant, si vous payez pas, on vous enleve votre compte», tout les rapports sont perdus. Je pense que c'est pire que l'histoire BitKeeper, parce que perdre des rapports de bugs, c'est quand même différent de changer d'outils de gestion de version.

On remarquera que c'est pareil avec launchpad.

D'après http://www.matbe.com/actualites/38511/asus-eee-box/ c'est le système de ventilation qui est bruyant. Et si tu regardes les photos, tu vois le gros ventillateur...

Ouais, OSM en WTFPL ! ;-)

Si, y'a une flèche en bas à gauche qui donne le sens (moyen?) du segment sélectionné. Bon, ca marche pas top avec les voies biscornu par contre, genre les bretelles d'autoroutes.

J'ai l'impression que ca change un peu. Voir http://openbsd.org/plus.html

- Make PowerPC SMP machines not grab biglock for syscalls marked SY_NOLOCK.
[...]
- Make i386 MP kernels not grab biglock for syscalls marked SY_NOLOCK.
[...]
- For amd64 and sparc64, do not grab kernel biglock for syscalls marked SY_NOLOCK.

> Ici, la faille ne provient pas du générateur lui-même, du fait que sur 32000
> et des brouettes personnes qui utilisent OpenSSL, 2 ont exactement la
> même suite aléatoire.

Pas du tout, efface... http://fr.wikipedia.org/wiki/Paradoxe_des_anniversaires

tu peux être sur que sur 32000 clef, au moins 2 on la même, mais la proba que sur 100 personnes, au moins deux aient la même clef est élevé...

> J'aimerais savoir combien de développeur d'OpenSSH utilisent debian
> comme poste de travail ?

0, OpenSSH est développé dans le CVS d'OpenBSD, donc sous OpenBSD. En effet, il est développé directement pour OpenBSD, et en parallèle, une version portable est réaliser. Voir http://openssh.org/portable.html

OpenSSH n'a pas de faille, c'est OpenSSL qui cause le problème, et uniquement la version d'origine Debian. OpenSSL est un autre projet, qui n'a rien à voir avec OpenSSH ni OpenBSD (à part son utilisation, et que la version OpenSSL d'OpenBSD est patché).

Il me semble que c'est pas globalement Webkit qui pose problème, mais webkit-gtk qui n'est pas encore vraiment fini. Le problème est donc plutôt que libwebkit-gtk est encore en stade alpha plutôt que "n'est pas génial", sous entendu possède des problèmes de conception, comme c'est le cas pour Gecko.

(allez exemple quand tu dis :
de cette branche (non officielle et experimentale, j'insiste) par contre tu n'insiste pas, bizaremmenet, sur le fait qu'elle était publique la branche...

Si elle n'etait pas publique, il n'y aurait pas eu de problème, vu que pas de redistribution. C'est donc nécessaire qu'elle le soit, donc c'etait pas la peine de le répéter.

Quand je disais que tu avais une mémoire sélective en ce qui concerne openbsd, je m'étais pas trompé.) [puis une suite de remarque limite injurieuse]

C'est pas une raison pour devenir agressif gratuitement...

typage statique : Le travail sur les types est intégralement fait à la compilation (donc rien n'est fait à l'exécution). Le contraire est typage dynamique, comme python, perl, ruby... Deux avantages à cela:
- aucune verification de typage n'est nécessaire à l'exécution, ce qui fait gagner du temps à l'exécution.
- La vérification est faite à la compilation, donc si les types utilisés sont incohérents, le code ne compile pas, contrairement au typage dynamique, où une exception est levé à l'exécution.

inférence de type : il n'y a pas besoin de donner les types des variables, le compilateur les infèrent à partir du code. Par exemple :
let f n = string_of_int nLe compilateur va trouver tout seul que le type de n est entier et que le type de retour de la fonction est chaîne de caractères.

polymorphisme paramétrique : C'est la possibilité pour un type d'englober un ensemble de type, avec des paramètres permettant une réutilisation du type plus loin. Par exemple :
let to_list n = [n]la fonction to_list prend un paramètre (qui peut être de n'importe quel type) et le transforme en une liste de type "liste d'éléments du type du paramètre. Le fait que la fonction puisse prendre un paramètre de n'importe quel type est le polymorphisme, le fait de pouvoir exprimer le type de la fonction grâce au type du paramètre est le paramétrique. Le code au dessus a pour type : 'a -> 'a list ce qui signifie une fonction prenant comme paramètre un paramètre de n'importe quelle type que l'on appelle 'a, et qui retourne une liste de type liste de 'a.

Et après, que fais tu des suggestions ? Même apt n'utilise pas ça à ma connaissance.

Hein ?

$ sudo apt-get install p7zip-full
Lecture des listes de paquets... Fait
Construction de l'arbre des dépendances
Lecture des informations d'état... Fait
Paquets suggérés :
p7zip-rar
Les NOUVEAUX paquets suivants seront installés :
p7zip-full
0 mis à jour, 1 nouvellement installés, 0 à enlever et 1 non mis à jour.
Il est nécessaire de prendre 0o/1189ko dans les archives.
Après cette opération, 2931ko d'espace disque supplémentaires seront utilisés.

Vista fin 2007 avait 10.5% de parts de marche, sachant que les ventes de boite representent ~10% des ventes, apres 1 an Vista aurait eu 2 fois plus de parts de marche que Linux en imaginant que PERSONNE n'achete Vista avec un PC, ce qui est illusoire...

Mmm, c'est vrai si on suppose que la vente en OEM est indépendante de la vente en boite, hypothèse qui me semble peu probable.

Il me semble que la partition pour le suspend to disk est pas forcément une partition de swap, ca peux être une partition tout simplement inutilisé.

Oui, j'ai bien compris, et ce n'est pas la même chose : si j'installe une bibliothèque à la main pour un programme que je compile, mais qui n'est pas utilisé par un autre package, urpme `urpmi_rpm-find-leaves -g` et la version debian utilisant deborphan vont m'enlever cette bibliothèque. Par contre, autoremove gardera cette bilbiothèque, car je l'ai installé moi-même, et c'est pas apt qui l'a installé à cause d'une dépendance.

C'est pas la même chose qu'autoremove.

L'équivalent apt de ce que tu donnes, c'est apt-get --purge remove `deborphan`autoremove propose d'enlever les paquets installés automatiquement par apt (genre libtrucmuch quand tu installes progfoo) qui n'est plus nécessaire (genre la mise à jour de progfoo ne dépend plus de libtrucmuch).

Ferme ta session X, elle est pas GPL :P

Je ne comprends pas. Tu veux dire qu'il n'y a pas de généralité ? Qu'on a toujours max > nom mais qu'il n'existe pas de N tel qu'on ait toujours en général et par sécurité max > N x nom ?

Oui, c'est ce que je veux dire. En fait, en conception, il faut que les pics de consomations soient inférieurs au max, et c'est tout. En pratique, je n'ai constaté aucun lien, d'autant plus que, souvent, les alims prennent une marge de sécu en proportion avec l'évolutivité du produit (possibilité d'ajouter des composant energievore).

Je voulais dire que pour installer un serveur chez soi il ne suffit pas que la machine tienne la charge, il faut aussi avoir une connexion perso suffisante en UL pour que ça rame pas trop du point de vue de l'utilisateur.

OK, OTAN pour moi.

Soit vingt fois plus.

Oui, d'ou l'interret de ces petites boites pour du serveur.

Je n'ai en fait aucune idée d'un rapport normal entre les deux.

Il n'y a en général pas plus que nominal < max.

Si c'est pour faire un server, le VGA et la sortie audio m'importent peu. Mais le wifi aussi, en fait.

En fait, l'utilité que j'en ai personnellement, c'est un serveur routeur. Comme dans serveur, il y a serveur mpd, la sortie audio est importante. Le VGA ne l'est pas, c'est juste une facilité. Mais bon, chacun a ses besoins spécifique ;-)

Une chose à laquelle je n'ai pas pensé, en terme de perf, c'est l'upload. En ADSL, c'est peut-être limitant.

Il me semble qu'une soekris 4800 est suffisante pour chiffrer le débit de l'upload ADSL, donc pas de problèmes avec les geodes à 500MHz. Sur http://www.kd85.com/ y'a le bench de ssl.

Je devrais mesurer la conso de mon PC, elle est peut-être beaucoup plus faible que je ne l'imagine.

Mon sempron 2800 avec une carte nvidia intégré (d'il y a 3-4 ans) et un écran TFT 15" consomment en tout 120W (dont 15W du moniteur je pense). Je crois que l'alim est une 200W (barebone).

PS : à propos, Microsoft est membre du consortium OCaml. Je me dis qu'ils ont du repérer une pépite dont ils pouvaient tirer qques enseignements...

Microsoft utiliserait OCaml pour la certification des drivers de Windows.

Dans .NET, on trouve beaucoup d'idée venant d'OCaml, notamment l'inférence de type et le typage statique. .NET possède même un clône d'OCaml : F#.

Quand tu mets dans un debugger un programme sans symbole, oui (et l'utilité est fortement limitée). Quand tu débuggues un programme impératif, tu es dans un contexte impératif. Quand tu débuggues un programme fonctionnel, tu te trouves dans un contexte fonctionnel. Voir http://caml.inria.fr/pub/docs/manual-ocaml/manual030.html (et encore, c'est trompeur vu que tu peux faire de l'itératif en OCaml).

Mais je ne suis pas sur que ce soit le cas de la majorité des programmeurs "impératifs".
Ils ont tous plus ou moins cette même perception, que ce soit à travers un débuggueur ou tout simplement en constatant la façon dont le code est exécuté.

héhé... en utilisant un débuggueur d'un langague impératif, on comprend mieux comment marche notre programme impératif ? On comprend mieux comment s'exécute un programme impératif en pensant en impératif ? C'est un peu totologique, non?

Non je penses plutôt à sa façon d'exécution les instructions du logiciel, ce qui est encore ce que produit le développeur quoi.

J'ai pas compris cette phrase, ou alors je vois pas en quoi elle contredit ce que je dis. Je crois que tu sous-entends qu'un logiciel ne se comprend qu'en impératif, ce qui n'est pas le cas.

Ben justement on connaît le fonctionnement de l'ordinateur pour exécuter un logiciel, et c'est cette proximité avec la représentation d'un code procédural qui fait que ce dernier est plus facile à apréhender.

Ma thèse, c'est le contraire : Le code procédurale est ce qui est le plus utilisé, ce qui fait que les gens pensent plus facilement en impératif (finalement, c'est pas vraiment ca ma thèse, mais l'idée est là). D'autre part, le code impératif est plus proche de la machine. Il n'y a pas de lien entre le fait qu'une machine fonctionne en impératif et le fait que les gens semblent appréhender plus facilement l'impératif. Au passage, le procédural, c'est pas vraiment proche de comment marche la machine, la machine n'a pas de procédure, juste des "goto".

J'ai dit que c'était plus intuitif de comprendre ce que fais un code impératif car sa lecture suit le déroulement de son exécution par la machine. Bref on "pense" mieux le comportement du soft.

Je ne vois pas en quoi [la] lecture [de code impérative] suit le déroulement de son exécution par la machine plus que la lecture de code fonctionnel. Et je comprends pas pourquoi tu parles de la machine ici.

pour moi le mode impératif est beaucoup plus "facile" à comprendre

Ca, je suis d'accord : tu peux trouver l'impératif plus facile à comprendre. Je suis pas d'accord avec ta justification comme quoi c'est parce que c'est proche de la machine (ou la notion que j'ai pas compris).

Par contre, à mon avis, un code impératif est plus difficile à comprendre qu'un code fonctionnel. Par contre, il est plus difficile (et donc plus long) d'apprendre et de maitriser le paradigme fonctionnel que le paradigme impératif. On en conclu donc que les gens qui ne veulent pas entendre parler du fonctionnel sont des gens pas assez fainéant : l'investissement de l'apprentissage du fonctionnel sera rapidement rentabilisé par la rapidité de lecture et d'écriture de code par la suite.

Tu penses aux transistors dans le cpu ? tu penses à la gestion des registres du processeur pour gérer ton code ? Non, je ne pense pas.

Que tu penses en impératif parce que tu y es habitué, je veux bien, mais dire que tu pense en impératif parce que ton cpu fonctionne comme ca me parrait fallacieux.

Mon avis, qui me semble plus crédible que ton avis (qui est que tu penses en impératif parce que ton ordinateur pense en impératif) est que l'on pense comme on est habitué à penser (je dirais même que l'on pense avec la langue que l'on connait, ce qui est la thèse de certains linguistes).

Perso, après avoir fait beaucoup de C, je me suis mis à OCaml. Après quelques temps à avoir du mal avec le langague, je me suis mis à penser en fonctionnel, et OCaml est devenu beaucou plus simple à utiliser. Maintenant, quand je code en C, j'ai même tendance à penser fonctionnel (sauf qu'en pratique, ca marche pas bien, et qu'on se remet à penser en impératif pour réussir à programmer ce qu'on veux).

Non, c'est pas parce que les ordinateurs fonctionnent de manière impérative que c'est plus facile de s'imaginer le déroulement du code que t'es en train d'écrire. C'est parce que tu es habitué à l'impératif que tu t'imagines plus facilement le déroulement du code impératif que tu es en train d'écrire.

Comprendre qu'il n'y a aucun lien entre le fait que les ordinnateurs fonctionnent de façon impérative et le fait que tu comprènes plus facilement le code impératif.