benoar a écrit 4229 commentaires

Tu précises que tu es à coté de la plaque, effectivement, ici on parle des syscalls, donc de l'interaction avec l'espace utilisateur, ce qui n'a rien à voir avec l'histoire de VMWare qui est un module.

Heu, je voudrais pas dire, mais tu as quand même omis de préciser que les "parties" devaient être compatibles GPL dans ton premier commentaire, d'ailleurs tu as même précisé :
ce qui n'impose /rien/ sur les licences des parties de l'ensemble
Alors que justement, la GPL impose que les "parties" soient compatibles GPL. Je te trouve un peu dur avec GeneralZod sur ce commentaire ...

http://www.kernel.org/pub/linux/docs/lkml/#s1-19
La violation de la GPL est toujours ambigüe. Je ne dirais pas qu'il ne violent pas la GPL clairement, mais un peu quand même. (cf mon commentaire plus bas)

Cet article date un peu, je ne l'ai pas relu en entier, mais de ce que je me souviens : VMWare utilise Linux pour booter, et après charge un module proprio qui est chargé de la virtualisation. Le truc, c'est qu'à priori, ce module est du code qui existait déjà avant de manière "séparée" du kernel, et qu'il a été "adapté" en tant que module. A priori, Linus ne considère pas ça comme une violation de la GPL (j'avais vu ça dans les commentaires de l'article). Et c'est souvent la défense qu'ont des constructeurs qui "adaptent" des drivers utilisés dans d'autres OS à Linux (genre Broadcom qui porte ses drivers depuis VxWorks).

En gros, c'est "si ce code fonctionne aussi avec autre chose que Linux, ce n'est pas une violation". J'avoue que ça fait quand même une brèche énorme dans la GPL, mais c'est pas complètement idiot non plus, dans le sens où si je crée un logiciel proprio qui a la même interface (API) qu'un logiciel libre, mais que je crée aussi la lib proprio qui va avec, et que je reste dans mon coin sans utiliser de libre du tout, peut-on m'attaquer parce que mon logiciel "pourrait" fonctionner avec la lib GPL (puisqu'ils ont la même interface) mais que je ne fourni pas le code sous GPL ?

Et on en arrive donc aussi au problème de licence d'un format ou d'une API : peut-on mettre une licence sur un format/protocole/API ? A première vue, ça parait débile, et c'est ce que fait MS avec OOXML, .Net et compagnie avec son "Open Specification Promise", même si là il se protège par ses brevets plutôt que par une licence . Mais quand on y pense, c'est un peu ce qui arrive avec cette histoire de VMWare : si on adapte son logiciel à une "interface sous GPL" (i.e. on s'interface en tant que module noyau), cela nous oblige-t-il à quelque chose, c'est à dire, est-on soumis à une licence ?

J'avoue que je n'apporte que peu de réponses et beaucoup de question, mais c'est important d'y réfléchir alors qu'aujourd'hui les problèmes de licence et d'interopérabilité, en particulier avec la GPL, sont de plus en plus discutés.

Pour le site en flash,c'est un peu lourd de ne pas avoir fait une version html simple, mais je ne vois pas trop pourquoi certains en concluent des choses au niveau de l'interoperabilité, même si le webmaster de bull ne pense pas aux 0,00000001 % de décideurs pressés qui tournent sur du linux PPC uniquement.
Le principe de l'interopérabilité, c'est que _n'importe qui_ puisse implémenter un logiciel compatible avec ce format. Ici, c'est donc de la _compatibilité_ avec Linux x86.
Ce n'est pas parce qu'une minorité ne peut accéder à ce format qu'on est interopérable. On n'est pas "quasi-interopérable" : soit on a les specs qu'on peut implémenter directement, soit j'appelle ça de la compatibilité.

Quand tu dis que l'impératif représente mieux ta manière de penser, je pense que c'est parce que tu connais ce qui se passe au bas niveau (tu parlais d'asm dans un de tes commentaires). Mais je ne suis pas sur que ce soit le cas de la majorité des programmeurs "impératifs". A ce moment-là, je ne vois pas en quoi ce serait plus "facile" de commencer par l'impératif.

Ha, juste une précision :
Globalement l'argument généralement utilisé qui consiste à dire que si l'impératif est généralement considéré comme plus facile c'est parcqu'on commence par ça me paraît fallacieux (c'est moche c'est mot c'est hallucinant) : mon expérience montre qu'en commencant par le le fonctionnel, c'est pas mieux.
Toi qui parlais plus haut des tournures de phrases tarabiscotées, celle-ci ne veut rien dire : pas mieux que quoi ?

Je pense que tu as raison pour l'enseignement en début de cursus, car j'ai eu des cours de CamL en master 1, et après 3 ans de "déformation" procédurale/objet, quasiment tous mes camarades ont vomis dessus tellement ils trouvaient ça compliqué, inutile et "pour chercheurs"..

Ouai, c'est la nouvelle mode.
Je pense que si je devais tester mon code en C avec tous les compilos, ça deviendrait assez vite un cauchemard.
Sauf que dans le monde du Web, c'est normal ...

C'est marrant, je verrais bien l'analogie Linux/Windows.
Oui, 95% des gens sont habitués à Windows, et ne veulent pas apprendre de nouvelles manières de faire parce que leur système, même s'il n'est pas parfait, leur "convient". Mais je dirais qu'il ne se rendent pas compte de ce qu'ils loupent. Surtout si on fait la comparaison OSX/Windows.

Et bien c'est pareil en programmation. 95% des devs font du procédural/objet, et ne veulent pas faire l'effort de changer leurs habitudes. Pourtant, beaucoup des problèmes que je vois résolus chaque jour dans tout un tas de langages auraient déjà disparus depuis longtemps si un peu plus de gens s'étaient intéressé à la prog fonctionnelle. C'est dommage, car quand je montre certaines possibilités "fonctionnelles" en python (pour ne pas faire trop peur avec un vrai langage fonctionnel), pas mal de programmeurs me disent "houa, c'est génial".

Bref, ceci n'est pas un jugement mais une sorte de mise en perspective d'un problème qu'on retrouve assez souvent. Doit-on tout uniformiser et utiliser le plus petit dénominateur commun afin de satisfaire tout le monde ? Est-ce que changer d'habitudes est trop dur pour 95% des gens ? Je ne sais pas. Mais je trouve dommage cette uniformité.

Moi, j'en suis quand même à hésiter à utiliser des closures en Javascript, alors que le langage s'y prête très bien et que ça "simplifie" énormément le code et la "manière" (je trouve ça plus naturel) de coder. Bon, ça doit être sur ce point que je fais une erreur, puisque ça n'a pas l'air si naturel que ça pour pas mal d'autre gens.

- Possibilité de sauver/restaurer une session X, un peu comme screen, très pratique pour éviter d'attendre 3 plombes qu'IntelliJ se lance;
Ha, ça m'intéresse : j'ai toujours cherché (enfin, quand je suis motivé) un logiciel qui permetterait de transférer des fenêtres X sur un serveur "virtuel" qui permetterait de les mettre en "standby" le temps de redémarrer X, par exemple, pour reprendre juste après.
D'après ce que tu dis, c'est possible de le faire avec NX, donc il doit y avoir moyen de faire ça pour la fonctionnalité que je recherche, non ?
Le truc c'est, est-ce une feature spécifique à NX et qui n'est pas "standard" dans le protocole d'X, ou est-ce un truc réalisable en restant compatible avec un X normal ?

OK, déjà j'ai fait une boulette (je ne suis pas vraiment doué en RAID), je pensais que la taille d'une stripe c'était _par_ disque, et non pour la totalité (moins le CRC). Je voulais donc plutôt dire une stripe de 8Ko, toujours sur 3 disques.

Pour les inconvénients :

1) effectivement, les têtes doivent être "synchronisées", mais je ne vois pas en quoi ça change le temps d'accès : c'est équivalent au temps d'accès à un disque, comme partout, non ?

2) oui, c'était la principale question que je me posais : l'OS travaille-t-il par secteur de 512 ou lit-il par 4Ko ? Quand tu mmap un fichier par exemple, tout est fait par page, non ? Par contre, tu as raison, ça va amener des problèmes d'atomicité ...

3) Je ne connaissais pas cette possibilité des disques, même si je supposais qu'il existait un mécanisme du genre. Par contre, de quel "trou" parles-tu ? C'est peut-être du à mon erreur du départ : ça devrait marcher correctement avec un stripe de 8Ko, non ?

Merci pour tes explications.

Argh, désolé du collé malencontreux.

J'ai oublié de préciser une chose dans mon hypothèse d'une page = une stripe, c'est que l'OS lise la taille d'une page/stripe complète à la fois.

Pendant que je tiens deux gars qui s'y connaissent, j'aimerais dériver un peu plus.istorique/20080401000000/20080401000000

Je compte me monter une bécane dont je compte tirer plusieurs choses au niveau des disques : de bonnes perfs, car pour moi un disque seul limite grandement les perfs, mais aussi un peu de sécurité si un disque clalque. Je sais, on peut pas tout avoir, peut-être que je demande la lune ...

Une question me vient quant au RAID 5, à propos des perfs en écriture : le système est obligé de relire les blocs à l'écriture, pour recalculer le CRC. Mais si la taille d'une stripe est égale à la taille d'une page en mémoire ? Je ne sais pas exactement comment se comporte la lecture d'un disque par rapport à la taille d'une page, mais imaginons que l'OS utilise des stripe de la même taille qu'une page, et qu'on lise à chaque fois tous les disques (-1) lorsqu'on veut lire un bloc ; alors, à l'écriture, aucune lecture n'aura besoin d'être faite, seulement 2 écritures. Par contre, contrairement à ton exemple, je dirais qu'il n'y a presque aucune différence (en dehors du calcul du CRC) qu'avec un seul disque (ou du RAID 1) puisque ces écritures sont réparties sur tous les disques !

Je voulais donc savoir si vous aviez plus d'info sur comment ça se passe, et ce que vous pensez de ma proposition de stripe à 4Ko.

J'ai bien aimé aussi l'interview de l'accusé dans un certains article (que je ne retrouve pas), où il disait "je ne suis pas éditeur car je ne contrôle pas le contenu", et un peu plus loin il précise "j'aurais enlevé l'article incriminé immédiatement si on me l'avait signifié avant que je me fasse condamner". Pas éditeur, mais il peut quand même choisir d'enlever un article si on lui signale ?...

Oui, effectivement, une fois qu'on a perdu un disque, il vaut mieux se dépêcher d'un remettre un autre.

Quant au prix, oui, effectivement, ça ne fait pas une différence énorme.
Par contre, je m'intéresse aussi à la place dans un boitier (c'est pour un desktop, pas pour un serveur), la conso électrique, et le bruit ... ce qui fera peut-être la différence entre RAID5 ou 1. Bon, tu va me dire, quand on a déjà 3 disques, un de plus ...

Vu que tu répondais à Sébastien, je pensais que tu parlais du RAID 5 comme "mauvais" à cause du problème du "degraded & dirty".

Quant au taux de panne plus elevé, que veux-tu dire ? Que plus de disques peuvent tomber en panne en RAID 1 avant de perdre des données ? Oui, mais le RAID 5 est fait pour être plus économique, non ?

Pour les perfs, tu as des chiffres ?

Ce n'est pas d'une manière aggressive de dire ça, mais ça m'intéresse de savoir les désavantages que je vais avoir en RAID 5 ...

Pas tant que ça, même si c'était effectivement dans la continuité du message de Sébastien. Ce qui m'a fait réagir, c'est ton "le RAID 5 n'a plus raison d'être", que je trouve quand même très exagéré...

D'un coté, quand on voit les perfs de gecko sur maemo ...

A propos de censure, d'autocensure, etc ... lire l'excellent "Dossier du Canard" (enchainé) qui parlait de ça, sorti aux alentours de décembre dernier il me semble (et qui doit être commandable sur leur site).

Si, tu as toujours le choix. Tu peux refuser d'aller voir ces informations.
Le fait de te plier montre encore plus ta dépendance, ta faiblesse, ton emprisonnement vis à vis de ses "puissances". Un peu comme un esclave, quoi. Si tu crois un peu à "l'égalité" de la devise française (= tout le monde a les même droit, pas "tout le monde est égal"), tu devrais refuser et condamner ce genre de pratiques.

Ouai enfin bon, déjà, des coupures de courant, chez moi, c'est _très_ rare, alors des coupures de courant qui font péter un disque en plus ... jamais vu. Même si, OK, ça peut aider à faire déconner le disque.

La plupart des disques que j'ai vu claquer, c'était en pleine marche normale de la machine. Ou alors un jour, en rebootant, hop, pu de disque. C'est conte ça que je veux me protéger (oui, je me suis intéressé à ce sujet car je compte faire du RAID 5 en soft sous nunux).

Ha OK, tu parlais de ce problème là. Mais je ne vois pas ce qu'une carte matérielle fait de mieux ; par contre, une carte avec une batterie pour finir les I/O, OK. Mais je suppose que c'est ce que tu voulais dire, c'est juste que sans préciser, je ne voyais pas le rapport ...

La Debian marche très bien sur les PPC aujourd'hui, je te la recommande vivement. Et la liste debian-ppc est pleine de ressources en cas de besoin.

Exactement.

C'est pour ça que je me demande vraiment ce que fait la config de wohlgi, vu que la plupart des BIOS qui font du fakeraid ne sont pas compatibles avec linux, donc je pense que la config du BIOS qu'il a faite ne sert strictement à rien.

C'est même pire que cela; le RAID-5 logiciel n'a pratiquement aucun avantage. La perte d'un disque risque de faire perdre toute la matrice contrairement au RAID-5 matériel.
Pourquoi ? T'as des sources ? Je ne vois pas de différence théorique entre les deux ...

Même à 100€, je ne connais pas de carte RAID matériel; les premiers prix tournent autour de 300€, et pour ce prix, on a rarement la batterie de secours qui permet de faire du RAID-5.
Oui c'est clair. Faire gaffe aux quelques cartes de "grandes marques" (Adaptec, ...) qui sont pas chères (genre 100€), mais qui sont en fait du fakeraid ...