Si je compile NPAPI moi même, je suis sur que ca va fonctionner. Et pour cause je l'ai déjà fait.
Si je compile l'interface Firefox moi même, je suis sur que le plugin DRM Adobe ne va pas fonctionner, pour des raisons de signature.
Et c'est ou que tu comprends pas que ce qui ne fonctionnerai plus si tu modifies le code, c'est le blob proprio?
Je me moque bien de savoir quelle partie de la chaine part en sucette.
Je ne touche pas au code => je peux lire mes vidéos
je touche au code => je ne peux plus lire mes vidéos, et c'est voulu (ie ce n'est pas une erreur de ma part)
Donc si je modifie le logiciel, je ne peux plus m'en servir. Il n'est pas libre.
Autre démo
Le plugin adobe qui gère les DRM ne sert à rien si il n'est pas interfacé avec un navigateur. L'interface navigateur de Firefox qui est développé par Mozilla d'accord pour que le plugin Adobe s'interface avec lui. le navigateur fait (beaucoup) plus que de juste lancer le plugin.
Cette interface navigateur est donc incompatible avec la GPL. La clause de compatibilité MPL -> GPL est donc baffouée. Cette interface n'est donc pas libre (A moins que Mozilla ne modifie sa licence MPL en conséquence pour la rendre compatible avec uen autre licence libre telle que MIT ou BSD)
Autre démo
L'interface Mozilla Firefox pour le plugin DRM est très, très probablement protégée contre l'execution sous controle, la rétro-analyse ou le debugage. I.E si j'utilise une de ces techniques, le plugin adobe sera probablement mis en rideau. Je n'ai donc pas la liberté d'analyse (comprendre le comportement de l'interface Mozilla est différent suivant qu'il y ait analyse ou non)
La liberté d'analyse est baffouée -> L'interface Mozilla Firefox n'est donc pas libre.
T'iras me trouver la ligne en question dans la GPL…
Alors
a) On parle de Mozilla Firefox qui est en MPL
b) La licence GPL v3 a été créé expressement pour résoudre un problème similaire (CF tivoisation)
c) quand tu cites un morceau de ce que je dis, essaye d'éviter de citer le contre exemple. J'imagine que la phrase que tu attaques est en fait "Le libre c'est la liberté de modification et d'utilisation, y compris d'utilisation de la version modifiée."
Maintenant regardons les quatres libertés fondamentales du logiciel libre selon la GNU :
Un programme est un logiciel libre si vous, en tant qu'utilisateur de ce programme, avez les quatre libertés essentielles :
la liberté d'exécuter le programme, pour tous les usages (liberté 0) ;
**la liberté d'étudier le fonctionnement du programme, et de le modifier pour qu'il effectue vos tâches informatiques comme vous le souhaitez (liberté 1) ;** l'accès au code source est une condition nécessaire ;
la liberté de redistribuer des copies, donc d'aider votre voisin (liberté 2) ;
la liberté de distribuer aux autres des copies de vos versions modifiées (liberté 3) ; en faisant cela, vous donnez à toute la communauté une possibilité de profiter de vos changements ; l'accès au code source est une condition nécessaire.
tu geins contre une société qui après tous les autres à finalement permis dans son navigateur de lire ces contenus.
Non plus.
Ce que je dis (sans franchement me plaindre d'ailleurs, enfin j'ai pas eu l'impression de raler à un moment quelconque), ce que je dis donc c'est qu'un programme qui a les caractéristiques suivantes :
Inutilisable sans un binaire propriétaire fermé, chiffré
Non modifiable sans le dénaturer (ie sans le rendre totalement inutile dans tous les cas possibles)
Dont la seule utilité est des restreindre/interdire l'accès à des données
ne peut pas être considéré comme libre, et ce quelque soit la définition de "libre" que l'on prenne.
Le fait qu'un étage de la chaine soit libre ne rend pas l'ensemble du logiciel libre.
tu veux lire des documents word => tu utilises un logiciel propriétaire
tu veux jour à des jeux => tu utilises un logiciel propriétaire
tu veux du matériel récent => tu utilises un logiciel propriétaire
tu veux faire de l'architecture => tu utilises un logiciel propriétaire
tu veux avoir accès à tous les contenus que tes amis t'envoient => tu utilises un logiciel propriétaire
tu veux pouvoir relire les contenus que tu as créé il y a quelques années => tu utilises un logiciel propriétaire
tu veux créer un film, le monter, le diffuser => tu utilises un logiciel propriétaire
etc.
Et si tu veux pas => OSEF, tu es libre.
Donc en fait tout est libre depuis le début. A part deux trois geignards dans mon genre qui ne comprennent rien à rien, il y a pas à s'inquieter puis qu'on est toujours libre de ne pas participer, de s'enfermer dans un cocon, de se couper du monde.
Tu pourra aller sur les sites qui utilisent le système de DRM implémenté par ton propre blob binaire.
A condition bien sur que je commence par rendre mon propre blob binaire non libre en m'assurant que toute personne qui chercherait à le modifier/l'analyser/le contourner se casse les dents dessus et soit obligé de recommencer tout à zéro. (Sinon autant ne pas mettre de DRM du tout - pourquoi alourdir le traffice avec des données que tout le monde peut contourner ?)
Et tu n'a pas le droit de faire tourner ton propre blob dans ce bac-à-sable modifié ? Si ? Tu peux le modifier et le redistribuer sous les termes de sa licence (libre), donc il est libre.
Et si tu fais ça tu peux aller sur les sites qui utilisent le système DRM d'Adobe et regarder tes contenus ? Non, bien sur que non. Tu as ta version du blob binaire qui ne sert à rien. (On va même dire qu'elle ne marche pas, même si techniquement elle n'a aucun bug.)
Une fois que tu as ta version modifiée de la sandbox et ta version modifiée ou nouvelle du blob DRM, il faut encore que tu recréées NetFlix et que tu tournes un petit milliers de films/séries/documentaires tous les ans pour que ca serve à quelque chose.
Sinon tu as une fois de plus un ensemble de programmes qui ne servent à rien.
Non.
Le libre c'est la liberté de modification et d'utilisation, y compris d'utilisation de la version modifiée.
Là on a une sandbox dont la seule utilisation est d'encapsuler un plugin binaire pour la gestion des DRM.
Si on veut l'utiliser on ne peut pas le modifier, et si on le modifie on ne peut plus l'utiliser.
Le fait que le code soit open source et débarassé de contraintes légales ne le rend pas libre.
Est-ce que je peux améliorer (dans le sens rajouter des fonctionnalités sans détruire l'existant) la sandbox ? Probablement pas, ou alors avec d'ennormes difficultés.
Est-ce que si j'arrive à créer une nouvelle version fonctionelle de la sandbox, j'ai le droit de la redistribuer ? Même pas en rêve aux US, seuelement sous couvert de travail de recherche et d'éducation en Europe.
si Office est très vendu sur iOS, arrêter de le vendre fera s'écrouler le chiffre d'affaire de… Microsoft
Oui et non. En stratégie propriétaire fermée, la compatibilité est autant un plus qu'un handicap. Si Office existait sur Linux j'en aurai déjà acheté des pelletées, mais très probablement que Microsoft vendrait moins de windows et aiderait à créer une vraie concurrence sur un marché sur lequel ils sont très largement leader (En marché pro, mac a du mal à se faire une place).
Aucun intéret donc pour eux à aller vers la compatibilité.
A l'inverse sur le marché des smartphones/tablettes c'est Apple qui est leader - jouer le coup de poker est certes risqué (quand on menace, il faut agir derrière sous peine de perdre de la force) mais peu s'avérer payant. Même si 15% des futurs utilisateurs Office iOS venaient à migrer de Ipad vers WinMobile ca ferait une augmentation de revenus assez conséquente pour MS (non seulement plus de royalties à verser sur ces 15%, mais en plus des royalties sur le hardware, l'OS, les autres applis etc.) - sans compter une montée en puissance de la plateforme niveau utilisateur, et donc un intéret economique plus grand pour les partenaires, les devs, les créateurs de contenu etc.
Après ca s'étudie bien sur, mais utiliser Office comme un cheval de Troie est une approche tout à fait valable commercialement.
Ca s'appelle l'inter-dépendance économique
Oui mais là elle est assez faible. L'URSS avait un grand besoin des revenus procurés par la vente des énergies naturelles, et l'Europe avait un grand besoind e ces énergies après les chocs pétroliers pour assurer sa croissance.
Ici la situation est différente, à aujourd'hui Microsoft n'a pas besoin d'iOS pour vendre Office - c'est juste un plus, et Apple n'a pas besoin d'Office pour vendre des Ipad.
La création d'un nouveau produit peut soit faire perdurer cet état, soit faire que les gens délaissent complètement les ordinateurs classiques pour des tablettes à la pomme, soit faire que les gens développent de nouvelles habitudes dans lesquelles Office iOS joue un rôle central.
La troisième option est à mon sens tout à fait plausible, c'est même je pense la plus probable (opinion personelle toussa - mais ca fait 20 ans que tout le monde cherche à tuer Office avec un succès modéré)
En même temps faut mieux lâcher 30% à Apple que de ne rien vendre du tout :)
Attend que Office soit disponible sur iOS depuis 4 ou 5 ans, quand tout le monde trouvera ca super pratique de lire, éditer, modifier les docs du boulot sur son Ipad. Si le produit est bon, Microsoft sera en mesure de demander à Apple de faire sauter les 30% sous peine de retrait de l'appli ce qui pousserait les utilisateurs habitués à migrer vers (au hasard) windows mobile.
Je ne comprends toujours pas. Si les contrôleurs Sata ont choisi la méthode bête pour faire un cache, qu'est-ce qui empêche de faire un cache moins bête dans une autre génération de disque ?
Le cout j'imagine principalement.
Une mémoire de tag, c'est pas sorcier. Pour 1go, tu stocks (1024*1024/4) blocs de 4k. Pour des clefs 48 bits, cela te fait un tag de ~2 Mo, cela n'est pas énorme.
C'est pas spécialement la place prise par les données qui pose problème, c'est le suivi et l'indexation des données, notamment lors d'une copie d'un lot de blocs sur un autre avec modification du lot de blocs source par la suite. Il faut également suivre les modifs faites en cache, recoller les morceaux si on demande d'ouvrir plusieurs lots de blocs qui ont des blocs en commun. etc. Et faire le tout suffisament vite et efficacement pour que ce soit interressant au niveau perf. Savoir gérer les problèmes ("tu sais le fichier que tu modifies depuis 10 minutes en cache, et ben en fait je peux pas le sauvegarder, il y a un secteur deffectueux") et pleins d'autres chose.
Je ne comprends pas pourquoi, il serait si difficile de faire un remapping des blocks en cache, et que tout reste cohérent ensuite.
Ca existe, ca s'appelle SCSI. Et c'est vraiment plus complexe que ca en a l'air. Même la version simpliste de l'exemple que j'ai donné fini par poser des problèmes dans certains cas particuliers. Les problèmes principaux sont liés au double double addressage sur un disque dur. A savoir l'adresse du bloc et l'adresse à l'intérieur du bloc du point de vue du disque et l'adresse du bloc et l'adresse à l'intérieur du bloc du point de vue de l'OS.
Pour que le cache soit efficace il faut être capable de mapper l'un sur l'autre très vite pour pouvoir dire facilement et rapidement si un bloc demandé par l'OS est disponible en cache ou pas. La norme SATA a résolu ce problème en utilisant non pas les adresses mais les commandes comme clefs. C'est beaucoup plus simple (et donc beaucoup moins cher) mais c'est loin d'être aussi efficace.
En résumé, la méthode soft poutre de sa maman ours et surtout est très malléable
Au niveau benchmark, le SATA RAID soft va poutrer de façon monstrueuse le SAS RAID hard. Tout ce qui est interressant dans le SAS RAID hard (accès concurrents, CPU libéré, accès direct en modification, réorganisation dynamique de demandes très variées venant de plusieurs utilisateurs etc.) va disparaitre dans les benchs.
Généralement les benchs sont fait en version mono utilisateur, quasi mono tache et sur un disque vierge de toute fragmentation. Dans la vie réelle ca se passe pas vraiment comme ça.
Lance 6 ou 7 Bonnie ++ en parallèle sur un ordi sur lequel il y a déjà 5 superpi (nb coeur + 1 en fait) qui tournent et là on verra la gueule que fait ZFS comparé à un RAID hardware.
Je ne comprends pas comment cela peut être un overkill. Si c'était le cas, les caches SSD ne servirait à rien.
Le cache des SSD sert dans le sens ou il est plus rapide que le SSD lui même et permet donc d'avoir de meilleurs temps de réponses quoi qu'il arrive, également les gros cache SSD évitent que les fichiers qui sont modifiés continuellement par l'OS (au hasard /var/log/syslog) ne détruisent la durée de vie du SSD.
L'hybridation SSD/HD sert dans le sens ou le SSD est plus rapide que le HD et que l'on a des Go d'espace de stockage.
Maintenant dans le cas d'un cache classique sur un disque SATA la question est "quelle quantité de cache on peut raisonnablement remplir avant que le principe de fonctionnement du SATA ne nous oblige à faire un sync ?", question qui peut se résumer en SATA à "combien de cache va-t-on remplir avant qu'il y ait besoin de dupliquer un fichier dans le cache ?". Le SATA n'a pas de mapping des blocs, il lui est donc très difficile de faire croire à l'OS qu'il travaille sur le disque dur alors qu'il travaille en fait sur du cache. La conséquence est que le SATA n'est pas adapté du tout à la modification d'un fichier qui est déjà en cache. On peut recréer une autre entrée cache pour remplacer la première mais au moment du sync il faudra écrire les deux entrées l'une par dessus l'autre pour rester cohérent. Sur le coup on va gagner un peu de perfs, mais au sync on va doubler les I/O et là c'est le drame. (Une fois de plus je simplifie, l'OS et le NCQ font que les I/O ne sont pas vraiment doublées mais l'overhead va quand même être important).
La norme SATA fait que les disques ne sont pas très intelligent au niveau du cache, pour accéder à un cache SATA il faut demander exactement le même ségment que celui qui est dans le cache. Ou alors le segement qui est juste avant ou alors le segment qui juste après. Par exemple si dans le cache vous avez le segment xDEF -> xFFE et que vous demandez le morceau xEEA -> xEEC dans 99.9% des cas vous allez entrainer un sync/read plutôt qu'un accès cache. C'est pour ça qu'il vaut mieux parler de buffer disque plutôt que de cache dans le cas du SATA. La clef pour accéder à un segment du buffer va être une commande, ou un lot de commande plus qu'une adresse.
Sur un OS moderne, en utilisation classique avec des disques SATA, la quantité d'infos qu'il va y avoir dans le cache au moment ou ca devient contre productif de continuer à bourrer le cache plutôt que de syncer est très inférieure à 64Mo la plupart du temps. (Avant il y avait pleins de super docs qui montraient ca très bien sur le site SATA-I/O, maintenant la plus petite doc est à 25$ - cool.)
Si le but est d'avoir un sync rapide, et de la mémoire cache en écriture pléthorique, cela ne doit pas être difficile de mettre 1 Go de ram de cache d'écriture sur un disque dure au lieu de 32 Mo et d'avoir une super capacité pour finir un fsync en cas de coupure d'alimentation.
C'est pas tout à fait aussi simple que ça. Le disque dur doit en plus posséder une intelligence au niveau bloc (au minimum). Si tu fais du sync brut de fonderie tu vas à la catastrophe, si tu fais du sync en mode pur synchrone tu tues les perfs.
Par exemple tu copies un gros fichier comme copie d'un autre, puis tu modifies le nouveau fichier en changeant un caractère et tu modifies l'ancien fichier en changeant un autre caractère.
Si tu n'as pas d'intelligence au niveau bloc il va se produire un des deux scenarios suivant :
1) Mode synchrone pur
- demande de copie du fichier => "Ouhlà gros fichier,on va syncer plus tard"
- modification du nouveau fichier => "Bon ben on va syncer maintenant, merci de patienter le temps de la copie, pas touche au fichier en attendant"
- modification de l'ancien fichier => "Bon ben on va syncer maintenant, merci de patienter le temps de la copie, pas touche au fichier en attendant"
Conséquence : gros impact sur les I/Os notamment en cas d'accès concurrents. L'OS peut faire des pirouettes pour permettre la modification de l'ancien fichier alors que le nouveau n'est pas encore copié, mais au niveau disque c'est clairement pas top. (Et pourtant c'est ce qui se passe 90% du temps en SATA….)
2) Mode "brut de décoffrage"
- demande de copie du fichier => "Ouhlà gros fichier, on va syncer plus tard"
- modification du nouveau fichier => "Bon ben on va syncer maintenant, merci de patienter le temps de la copie, pas touche au fichier en attendant"
- modification de l'ancien fichier => "Un seul caractère ? Pas de problème gars - on fait ça tout de suite"
Conséquence : impact modéré sur les I/O, mais gros risque de corruption de données si la source du fichier en cours de copie est modifié.
En SAS (et en scsi en général) il va se passer ça (en ultra simplifié hein…):
demande de copie du fichier => "Les blocks Xxxx,Xxxy,….Xzzz sont faux, à la place utiliser les blocks Yxxx,Yxxy,….Yzzz en lecture"+" Planifier copie des blocs Yxxx,Yxxy,….Yzzz vers Xxxx,Xxxy,….Xzzz"
Modification du nouveau fichier => "Le bloc Xzxy est faux à la place utiliser cache Xaab" + "Anuler copie du bloc Yzxy vers bloc Xzxy"+"Planifier copie du bloc cache Xaab vers bloc Xzxy"
Modification de l'ancien fichier => "mettre en cache dans Xaad le bloc Yzyy" + "Le bloc Yzyy est faux à la place utiliser bloc cache Xaac" + "Le bloc Xzyy est faux à la place utiliser bloc cache Xaad"+"Planifier copie du bloc cache Xaac vers le bloc Yzyy"+"Annuler copie bloc Yzyy vers Xzyy"+"Planifier copie du bloc cache Xaad vers Xzyy"
Au niveau I/O, temps de réponses, opérations à effectuer pour un sync etc. on comprend assez vite que le SAS va booster grave.
Bien entendu il y a en plus des algos qui font que les écritures proches sont faites par lot, la gestion du cache est beaucoup plus puissante que ce qu'exposé dans cet exemple simpliste etc.
En SATA, la nature même du fonctionnement fait que le cache s'essouffle très vite. Il y a eu à une époque des disque SATA avec 256Mo, mais leurs perfs étaient à peine meilleure que les disques avec 32Mo. Honnêtement sauf à ballader à longuer de journée des fichiers qui font la moitié de la taille du cache disque, il n'y a aucun intéret à aller au delà de 64Mo en SATA, et déjà c'est overkill…
Je ne suis pas sûr que le RAID Hardware soit plus performant (et souple!) de nos jours
Sur le SAS rien que l'économie sur les opérations de sync, le cache énorme des cartes haut de gamme et le map des blocks par la carte approtent un gain de perfs assez violent par rapport à tout ce qui peut se faire en software, le tout pour une occupation CPU bien moindre, notamment sur tout ce qui va être mirroring ou fonctionnement dégradé (RAID 6 software avec un disque en panne… Ca pique)
Après au niveau flexibilité c'est clair que pour avoir quelque chose de comparable à la versatilité du RAID soft il faut mettre le prix. Mais généralement quand tu pars sur 6 ou 7000€ de matos pour avoir du raid hard (carte+disques+enclosure/backplane) tu sais ce que tu veux et tu ne t'amuses pas trop à changer la config ou à agrandir/réduire des disques toutes les 48h.
Après si tu veux vraiment la flexibilité ultime tu vas vite partir sur du iSCSI avec des baies dédiées et la question hard/soft ne se pose plus vraiment. FreeNAS qui est la seule alternative software crédible à ce jour est encore loin des perfs et de la fiabilité d'une baie proprio de grande marque. Même en moyenne gamme, pour à peine plus cher qu'un PC monté à la main avec FreeNAS dessus, un Thecus N1x000pro sera généralement meilleur (et plus simple à administrer) et pourtant c'est une LSI 2008 dessus, et c'est pas vraiment une foudre de guerre.
Bah, le RAID "Hardware" est surtout du software mis dans un CPU même plus trop dédié + RAM dédié, donc tant qu'à faire autant que ce soit sur le CPU principal et profiter de la mutualisation non? Le RAID "Hardware" avait une super réputaiton, mais de nos jours je le vois de plus en plus critiqué et je lis de plus en plus "prenez la gestion RAID de Linux".
Ca c'est vrai pour l'entrée de gamme qui prétend faire du raid mais qui délègue 80% du boulot à l'hôte.
Sur de la carte un peu plus costaud ca n'est plus vrai du tout, notamment au niveau des I/Os. Mais bon il faut compter entre 100€ et 200€ du canal pour avoir un produit convenable.
Et encore, même cela peut devenir impossible. Vu la direction que prennent les choses, dans moins de 10 ans, internet pour particulier ça ne sera que de la CONSULATION sur le port 80 et 443 (port tcp 80,443 SORTANT).
Il y aura toujours un hacker pour faire un tunnel basé sur le protocole multi-player de candy-truc.
Mais une fois de plus ca va concerner 0.01% de la population…
C'est bien entendu contournable. N'importe qui qui connait un peu le fonctionnement des VPN, Tunnels et autres redirections de ports et NAT transversal sera toujours plus ou moins capable de passer outre les limitations.
Ca fait 0,01% de la population internet qui peut accéder à ton contenu si elle en a le temps et l'envie.
Par la magie de la loi française, je tiens à rappeler que la diffamation inclue la vérité.
Et c'est une excellente chose. La diffamation relève du mensonge avec intention de nuire à l'image. Et le mensonge n'est pas l'opposé de la vérité. Le mensonge est l'opposé de la véracité et l'opposé de la vérité est la fausseté.
Si on se trompe, on peut parfaitement dire la vérité en mentant. De même que l'on peut parfaitement sortir une quantité absolument abhérantes d'anneries impossibles à adosser à des faits tout en étant persuadé d'être totalement franc et impartial (là pas besoin d'exemple, vous êtes sur LinuxFR vous devriez pouvoir trouver tout seul).
Le mensonge par omission qui consiste à négliger de mentionner certains faits ou éléments important pour la compréhension de l'énnoncé est un procédé (malheureusement) courant.
Euh il suffit de voir si le paquet est arrivé au niveau de la VM ou pas …
Déjà non. Parce que une fois de plus le comportement d'un kernel dans un environnement VM n'est pas identique à celui d'un kernel (au niveau latence, I/O, cache, temps de réponse du pilote hardware); et ensuite même si s'était le cas il faut également vérifier que le paquet n'a pas été altéré ou dénaturé soit par le kernel hôte, soit par la couche émulation carte réseau, soit par le pilote virtualisé. C'est seulement en ayant vérifié tout cela que l'on peut commencer à se demander si oui ou non ce paquet présente un risque pour la machine. Comment s'assurer de tout ça ? En mettant des sondes. Problèmes : il faut maintenant s'assurer que les sondes n'altèrent pas et ne dénaturent pas le paquet réseau, qu'elles n'ont pas d'influence sur les I/O, le cache, le comportement du kernel hôte etc. Comment faire çà ? En mettant d'autres sondes qui … euh…
Le problème est exactement le même que celui du programme qui crashe systématiquement à l’exécution, sauf en mode debug ou il tourne comme une horloge.
enfin à t'écouter, théo c'est plus une maison qu'il a, c'est un hangar de 1500 m² avec 2 lignes 20 kv.
Je crois qu'il n'y a "que" 200 ou 300m² dédiés aux machines. Par contre 40kVA ca va être juste, déjà moi je fais sauter mes 36kVA parfois (en pur particulier hein).
[^] # Re: Que de mauvaises intentions
Posté par Kaane . En réponse au journal Mozilla fait avancer le web et ajoute les DRM à Firefox. Évalué à 2.
Et quelle est la différence avec NPAPI
Si je compile NPAPI moi même, je suis sur que ca va fonctionner. Et pour cause je l'ai déjà fait.
Si je compile l'interface Firefox moi même, je suis sur que le plugin DRM Adobe ne va pas fonctionner, pour des raisons de signature.
C'est la principale différence.
[^] # Re: Que de mauvaises intentions
Posté par Kaane . En réponse au journal Mozilla fait avancer le web et ajoute les DRM à Firefox. Évalué à 4.
Je me moque bien de savoir quelle partie de la chaine part en sucette.
Je ne touche pas au code => je peux lire mes vidéos
je touche au code => je ne peux plus lire mes vidéos, et c'est voulu (ie ce n'est pas une erreur de ma part)
Donc si je modifie le logiciel, je ne peux plus m'en servir. Il n'est pas libre.
Autre démo
Le plugin adobe qui gère les DRM ne sert à rien si il n'est pas interfacé avec un navigateur. L'interface navigateur de Firefox qui est développé par Mozilla d'accord pour que le plugin Adobe s'interface avec lui. le navigateur fait (beaucoup) plus que de juste lancer le plugin.
Cette interface navigateur est donc incompatible avec la GPL. La clause de compatibilité MPL -> GPL est donc baffouée. Cette interface n'est donc pas libre (A moins que Mozilla ne modifie sa licence MPL en conséquence pour la rendre compatible avec uen autre licence libre telle que MIT ou BSD)
Autre démo
L'interface Mozilla Firefox pour le plugin DRM est très, très probablement protégée contre l'execution sous controle, la rétro-analyse ou le debugage. I.E si j'utilise une de ces techniques, le plugin adobe sera probablement mis en rideau. Je n'ai donc pas la liberté d'analyse (comprendre le comportement de l'interface Mozilla est différent suivant qu'il y ait analyse ou non)
La liberté d'analyse est baffouée -> L'interface Mozilla Firefox n'est donc pas libre.
etc. etc.
[^] # Re: Que de mauvaises intentions
Posté par Kaane . En réponse au journal Mozilla fait avancer le web et ajoute les DRM à Firefox. Évalué à 6.
T'iras me trouver la ligne en question dans la GPL…
Alors
a) On parle de Mozilla Firefox qui est en MPL
b) La licence GPL v3 a été créé expressement pour résoudre un problème similaire (CF tivoisation)
c) quand tu cites un morceau de ce que je dis, essaye d'éviter de citer le contre exemple. J'imagine que la phrase que tu attaques est en fait "Le libre c'est la liberté de modification et d'utilisation, y compris d'utilisation de la version modifiée."
Maintenant regardons les quatres libertés fondamentales du logiciel libre selon la GNU :
Un programme est un logiciel libre si vous, en tant qu'utilisateur de ce programme, avez les quatre libertés essentielles :
Voilà, voilà.
[^] # Re: Que de mauvaises intentions
Posté par Kaane . En réponse au journal Mozilla fait avancer le web et ajoute les DRM à Firefox. Évalué à 3.
Au lieu de te plaindre contre le principe des DRM
Ce n'est pas ce que je fais.
tu geins contre une société qui après tous les autres à finalement permis dans son navigateur de lire ces contenus.
Non plus.
Ce que je dis (sans franchement me plaindre d'ailleurs, enfin j'ai pas eu l'impression de raler à un moment quelconque), ce que je dis donc c'est qu'un programme qui a les caractéristiques suivantes :
Le fait qu'un étage de la chaine soit libre ne rend pas l'ensemble du logiciel libre.
C'est mon seul et unique point.
[^] # Re: Que de mauvaises intentions
Posté par Kaane . En réponse au journal Mozilla fait avancer le web et ajoute les DRM à Firefox. Évalué à 6.
Donc la dichotomie est simple :
tu veux lire des documents word => tu utilises un logiciel propriétaire
tu veux jour à des jeux => tu utilises un logiciel propriétaire
tu veux du matériel récent => tu utilises un logiciel propriétaire
tu veux faire de l'architecture => tu utilises un logiciel propriétaire
tu veux avoir accès à tous les contenus que tes amis t'envoient => tu utilises un logiciel propriétaire
tu veux pouvoir relire les contenus que tu as créé il y a quelques années => tu utilises un logiciel propriétaire
tu veux créer un film, le monter, le diffuser => tu utilises un logiciel propriétaire
etc.
Et si tu veux pas => OSEF, tu es libre.
Donc en fait tout est libre depuis le début. A part deux trois geignards dans mon genre qui ne comprennent rien à rien, il y a pas à s'inquieter puis qu'on est toujours libre de ne pas participer, de s'enfermer dans un cocon, de se couper du monde.
[^] # Re: Que de mauvaises intentions
Posté par Kaane . En réponse au journal Mozilla fait avancer le web et ajoute les DRM à Firefox. Évalué à 1.
Tu pourra aller sur les sites qui utilisent le système de DRM implémenté par ton propre blob binaire.
A condition bien sur que je commence par rendre mon propre blob binaire non libre en m'assurant que toute personne qui chercherait à le modifier/l'analyser/le contourner se casse les dents dessus et soit obligé de recommencer tout à zéro. (Sinon autant ne pas mettre de DRM du tout - pourquoi alourdir le traffice avec des données que tout le monde peut contourner ?)
Donc rendre mon système DRM non libre….
[^] # Re: Que de mauvaises intentions
Posté par Kaane . En réponse au journal Mozilla fait avancer le web et ajoute les DRM à Firefox. Évalué à 1.
Et tu n'a pas le droit de faire tourner ton propre blob dans ce bac-à-sable modifié ? Si ? Tu peux le modifier et le redistribuer sous les termes de sa licence (libre), donc il est libre.
Et si tu fais ça tu peux aller sur les sites qui utilisent le système DRM d'Adobe et regarder tes contenus ? Non, bien sur que non. Tu as ta version du blob binaire qui ne sert à rien. (On va même dire qu'elle ne marche pas, même si techniquement elle n'a aucun bug.)
Une fois que tu as ta version modifiée de la sandbox et ta version modifiée ou nouvelle du blob DRM, il faut encore que tu recréées NetFlix et que tu tournes un petit milliers de films/séries/documentaires tous les ans pour que ca serve à quelque chose.
Sinon tu as une fois de plus un ensemble de programmes qui ne servent à rien.
[^] # Re: Que de mauvaises intentions
Posté par Kaane . En réponse au journal Mozilla fait avancer le web et ajoute les DRM à Firefox. Évalué à 3.
Le code est légalement modifiable, il est libre.
Non.
Le libre c'est la liberté de modification et d'utilisation, y compris d'utilisation de la version modifiée.
Là on a une sandbox dont la seule utilisation est d'encapsuler un plugin binaire pour la gestion des DRM.
Si on veut l'utiliser on ne peut pas le modifier, et si on le modifie on ne peut plus l'utiliser.
Le fait que le code soit open source et débarassé de contraintes légales ne le rend pas libre.
Est-ce que je peux améliorer (dans le sens rajouter des fonctionnalités sans détruire l'existant) la sandbox ? Probablement pas, ou alors avec d'ennormes difficultés.
Est-ce que si j'arrive à créer une nouvelle version fonctionelle de la sandbox, j'ai le droit de la redistribuer ? Même pas en rêve aux US, seuelement sous couvert de travail de recherche et d'éducation en Europe.
Bilan : Est-ce que c'est libre ? Non.
[^] # Re: PostgreSQL, c'est mieux que MariaDB
Posté par Kaane . En réponse au journal Un dépôt MariaDB est aux abonnés absents. Évalué à 10.
PostgreSQL, c'est mieux que MariaDB
Ca n'a rien à voir, PostgreSQL est un logiciel de base de données…
[^] # Re: Satya Nadella
Posté par Kaane . En réponse au journal Microsoft libère leur compilateur C#. Évalué à 4.
si Office est très vendu sur iOS, arrêter de le vendre fera s'écrouler le chiffre d'affaire de… Microsoft
Oui et non. En stratégie propriétaire fermée, la compatibilité est autant un plus qu'un handicap. Si Office existait sur Linux j'en aurai déjà acheté des pelletées, mais très probablement que Microsoft vendrait moins de windows et aiderait à créer une vraie concurrence sur un marché sur lequel ils sont très largement leader (En marché pro, mac a du mal à se faire une place).
Aucun intéret donc pour eux à aller vers la compatibilité.
A l'inverse sur le marché des smartphones/tablettes c'est Apple qui est leader - jouer le coup de poker est certes risqué (quand on menace, il faut agir derrière sous peine de perdre de la force) mais peu s'avérer payant. Même si 15% des futurs utilisateurs Office iOS venaient à migrer de Ipad vers WinMobile ca ferait une augmentation de revenus assez conséquente pour MS (non seulement plus de royalties à verser sur ces 15%, mais en plus des royalties sur le hardware, l'OS, les autres applis etc.) - sans compter une montée en puissance de la plateforme niveau utilisateur, et donc un intéret economique plus grand pour les partenaires, les devs, les créateurs de contenu etc.
Après ca s'étudie bien sur, mais utiliser Office comme un cheval de Troie est une approche tout à fait valable commercialement.
Ca s'appelle l'inter-dépendance économique
Oui mais là elle est assez faible. L'URSS avait un grand besoin des revenus procurés par la vente des énergies naturelles, et l'Europe avait un grand besoind e ces énergies après les chocs pétroliers pour assurer sa croissance.
Ici la situation est différente, à aujourd'hui Microsoft n'a pas besoin d'iOS pour vendre Office - c'est juste un plus, et Apple n'a pas besoin d'Office pour vendre des Ipad.
La création d'un nouveau produit peut soit faire perdurer cet état, soit faire que les gens délaissent complètement les ordinateurs classiques pour des tablettes à la pomme, soit faire que les gens développent de nouvelles habitudes dans lesquelles Office iOS joue un rôle central.
La troisième option est à mon sens tout à fait plausible, c'est même je pense la plus probable (opinion personelle toussa - mais ca fait 20 ans que tout le monde cherche à tuer Office avec un succès modéré)
[^] # Re: Satya Nadella
Posté par Kaane . En réponse au journal Microsoft libère leur compilateur C#. Évalué à 2.
En même temps faut mieux lâcher 30% à Apple que de ne rien vendre du tout :)
Attend que Office soit disponible sur iOS depuis 4 ou 5 ans, quand tout le monde trouvera ca super pratique de lire, éditer, modifier les docs du boulot sur son Ipad. Si le produit est bon, Microsoft sera en mesure de demander à Apple de faire sauter les 30% sous peine de retrait de l'appli ce qui pousserait les utilisateurs habitués à migrer vers (au hasard) windows mobile.
[^] # Re: Pour moi, XML, c'est comme le PHP...
Posté par Kaane . En réponse au journal XML c'est de la daube!!!. Évalué à 10.
Mais non Perl est le meilleur langage jamais lu.
C'est pas du tout la même chose.
# .ob1
Posté par Kaane . En réponse au sondage Quel est le TLD le plus crédible ?. Évalué à 10.
Quel newbie…
[^] # Re: Utilisation en production ?
Posté par Kaane . En réponse à la dépêche Et si la meilleure des cartes RAID était libre ?. Évalué à 2.
Je ne comprends toujours pas. Si les contrôleurs Sata ont choisi la méthode bête pour faire un cache, qu'est-ce qui empêche de faire un cache moins bête dans une autre génération de disque ?
Le cout j'imagine principalement.
Une mémoire de tag, c'est pas sorcier. Pour 1go, tu stocks (1024*1024/4) blocs de 4k. Pour des clefs 48 bits, cela te fait un tag de ~2 Mo, cela n'est pas énorme.
C'est pas spécialement la place prise par les données qui pose problème, c'est le suivi et l'indexation des données, notamment lors d'une copie d'un lot de blocs sur un autre avec modification du lot de blocs source par la suite. Il faut également suivre les modifs faites en cache, recoller les morceaux si on demande d'ouvrir plusieurs lots de blocs qui ont des blocs en commun. etc. Et faire le tout suffisament vite et efficacement pour que ce soit interressant au niveau perf. Savoir gérer les problèmes ("tu sais le fichier que tu modifies depuis 10 minutes en cache, et ben en fait je peux pas le sauvegarder, il y a un secteur deffectueux") et pleins d'autres chose.
[^] # Re: Utilisation en production ?
Posté par Kaane . En réponse à la dépêche Et si la meilleure des cartes RAID était libre ?. Évalué à 3.
Je ne comprends pas pourquoi, il serait si difficile de faire un remapping des blocks en cache, et que tout reste cohérent ensuite.
Ca existe, ca s'appelle SCSI. Et c'est vraiment plus complexe que ca en a l'air. Même la version simpliste de l'exemple que j'ai donné fini par poser des problèmes dans certains cas particuliers. Les problèmes principaux sont liés au double double addressage sur un disque dur. A savoir l'adresse du bloc et l'adresse à l'intérieur du bloc du point de vue du disque et l'adresse du bloc et l'adresse à l'intérieur du bloc du point de vue de l'OS.
Pour que le cache soit efficace il faut être capable de mapper l'un sur l'autre très vite pour pouvoir dire facilement et rapidement si un bloc demandé par l'OS est disponible en cache ou pas. La norme SATA a résolu ce problème en utilisant non pas les adresses mais les commandes comme clefs. C'est beaucoup plus simple (et donc beaucoup moins cher) mais c'est loin d'être aussi efficace.
[^] # Re: Utilisation en production ?
Posté par Kaane . En réponse à la dépêche Et si la meilleure des cartes RAID était libre ?. Évalué à 4.
En résumé, la méthode soft poutre de sa maman ours et surtout est très malléable
Au niveau benchmark, le SATA RAID soft va poutrer de façon monstrueuse le SAS RAID hard. Tout ce qui est interressant dans le SAS RAID hard (accès concurrents, CPU libéré, accès direct en modification, réorganisation dynamique de demandes très variées venant de plusieurs utilisateurs etc.) va disparaitre dans les benchs.
Généralement les benchs sont fait en version mono utilisateur, quasi mono tache et sur un disque vierge de toute fragmentation. Dans la vie réelle ca se passe pas vraiment comme ça.
Lance 6 ou 7 Bonnie ++ en parallèle sur un ordi sur lequel il y a déjà 5 superpi (nb coeur + 1 en fait) qui tournent et là on verra la gueule que fait ZFS comparé à un RAID hardware.
[^] # Re: Utilisation en production ?
Posté par Kaane . En réponse à la dépêche Et si la meilleure des cartes RAID était libre ?. Évalué à 7.
Je ne comprends pas comment cela peut être un overkill. Si c'était le cas, les caches SSD ne servirait à rien.
Le cache des SSD sert dans le sens ou il est plus rapide que le SSD lui même et permet donc d'avoir de meilleurs temps de réponses quoi qu'il arrive, également les gros cache SSD évitent que les fichiers qui sont modifiés continuellement par l'OS (au hasard /var/log/syslog) ne détruisent la durée de vie du SSD.
L'hybridation SSD/HD sert dans le sens ou le SSD est plus rapide que le HD et que l'on a des Go d'espace de stockage.
Maintenant dans le cas d'un cache classique sur un disque SATA la question est "quelle quantité de cache on peut raisonnablement remplir avant que le principe de fonctionnement du SATA ne nous oblige à faire un sync ?", question qui peut se résumer en SATA à "combien de cache va-t-on remplir avant qu'il y ait besoin de dupliquer un fichier dans le cache ?". Le SATA n'a pas de mapping des blocs, il lui est donc très difficile de faire croire à l'OS qu'il travaille sur le disque dur alors qu'il travaille en fait sur du cache. La conséquence est que le SATA n'est pas adapté du tout à la modification d'un fichier qui est déjà en cache. On peut recréer une autre entrée cache pour remplacer la première mais au moment du sync il faudra écrire les deux entrées l'une par dessus l'autre pour rester cohérent. Sur le coup on va gagner un peu de perfs, mais au sync on va doubler les I/O et là c'est le drame. (Une fois de plus je simplifie, l'OS et le NCQ font que les I/O ne sont pas vraiment doublées mais l'overhead va quand même être important).
La norme SATA fait que les disques ne sont pas très intelligent au niveau du cache, pour accéder à un cache SATA il faut demander exactement le même ségment que celui qui est dans le cache. Ou alors le segement qui est juste avant ou alors le segment qui juste après. Par exemple si dans le cache vous avez le segment xDEF -> xFFE et que vous demandez le morceau xEEA -> xEEC dans 99.9% des cas vous allez entrainer un sync/read plutôt qu'un accès cache. C'est pour ça qu'il vaut mieux parler de buffer disque plutôt que de cache dans le cas du SATA. La clef pour accéder à un segment du buffer va être une commande, ou un lot de commande plus qu'une adresse.
Sur un OS moderne, en utilisation classique avec des disques SATA, la quantité d'infos qu'il va y avoir dans le cache au moment ou ca devient contre productif de continuer à bourrer le cache plutôt que de syncer est très inférieure à 64Mo la plupart du temps. (Avant il y avait pleins de super docs qui montraient ca très bien sur le site SATA-I/O, maintenant la plus petite doc est à 25$ - cool.)
[^] # Re: Utilisation en production ?
Posté par Kaane . En réponse à la dépêche Et si la meilleure des cartes RAID était libre ?. Évalué à 7.
Si le but est d'avoir un sync rapide, et de la mémoire cache en écriture pléthorique, cela ne doit pas être difficile de mettre 1 Go de ram de cache d'écriture sur un disque dure au lieu de 32 Mo et d'avoir une super capacité pour finir un fsync en cas de coupure d'alimentation.
C'est pas tout à fait aussi simple que ça. Le disque dur doit en plus posséder une intelligence au niveau bloc (au minimum). Si tu fais du sync brut de fonderie tu vas à la catastrophe, si tu fais du sync en mode pur synchrone tu tues les perfs.
Par exemple tu copies un gros fichier comme copie d'un autre, puis tu modifies le nouveau fichier en changeant un caractère et tu modifies l'ancien fichier en changeant un autre caractère.
Si tu n'as pas d'intelligence au niveau bloc il va se produire un des deux scenarios suivant :
1) Mode synchrone pur
- demande de copie du fichier => "Ouhlà gros fichier,on va syncer plus tard"
- modification du nouveau fichier => "Bon ben on va syncer maintenant, merci de patienter le temps de la copie, pas touche au fichier en attendant"
- modification de l'ancien fichier => "Bon ben on va syncer maintenant, merci de patienter le temps de la copie, pas touche au fichier en attendant"
Conséquence : gros impact sur les I/Os notamment en cas d'accès concurrents. L'OS peut faire des pirouettes pour permettre la modification de l'ancien fichier alors que le nouveau n'est pas encore copié, mais au niveau disque c'est clairement pas top. (Et pourtant c'est ce qui se passe 90% du temps en SATA….)
2) Mode "brut de décoffrage"
- demande de copie du fichier => "Ouhlà gros fichier, on va syncer plus tard"
- modification du nouveau fichier => "Bon ben on va syncer maintenant, merci de patienter le temps de la copie, pas touche au fichier en attendant"
- modification de l'ancien fichier => "Un seul caractère ? Pas de problème gars - on fait ça tout de suite"
Conséquence : impact modéré sur les I/O, mais gros risque de corruption de données si la source du fichier en cours de copie est modifié.
En SAS (et en scsi en général) il va se passer ça (en ultra simplifié hein…):
Au niveau I/O, temps de réponses, opérations à effectuer pour un sync etc. on comprend assez vite que le SAS va booster grave.
Bien entendu il y a en plus des algos qui font que les écritures proches sont faites par lot, la gestion du cache est beaucoup plus puissante que ce qu'exposé dans cet exemple simpliste etc.
En SATA, la nature même du fonctionnement fait que le cache s'essouffle très vite. Il y a eu à une époque des disque SATA avec 256Mo, mais leurs perfs étaient à peine meilleure que les disques avec 32Mo. Honnêtement sauf à ballader à longuer de journée des fichiers qui font la moitié de la taille du cache disque, il n'y a aucun intéret à aller au delà de 64Mo en SATA, et déjà c'est overkill…
[^] # Re: Utilisation en production ?
Posté par Kaane . En réponse à la dépêche Et si la meilleure des cartes RAID était libre ?. Évalué à 7.
Je ne suis pas sûr que le RAID Hardware soit plus performant (et souple!) de nos jours
Sur le SAS rien que l'économie sur les opérations de sync, le cache énorme des cartes haut de gamme et le map des blocks par la carte approtent un gain de perfs assez violent par rapport à tout ce qui peut se faire en software, le tout pour une occupation CPU bien moindre, notamment sur tout ce qui va être mirroring ou fonctionnement dégradé (RAID 6 software avec un disque en panne… Ca pique)
Après au niveau flexibilité c'est clair que pour avoir quelque chose de comparable à la versatilité du RAID soft il faut mettre le prix. Mais généralement quand tu pars sur 6 ou 7000€ de matos pour avoir du raid hard (carte+disques+enclosure/backplane) tu sais ce que tu veux et tu ne t'amuses pas trop à changer la config ou à agrandir/réduire des disques toutes les 48h.
Après si tu veux vraiment la flexibilité ultime tu vas vite partir sur du iSCSI avec des baies dédiées et la question hard/soft ne se pose plus vraiment. FreeNAS qui est la seule alternative software crédible à ce jour est encore loin des perfs et de la fiabilité d'une baie proprio de grande marque. Même en moyenne gamme, pour à peine plus cher qu'un PC monté à la main avec FreeNAS dessus, un Thecus N1x000pro sera généralement meilleur (et plus simple à administrer) et pourtant c'est une LSI 2008 dessus, et c'est pas vraiment une foudre de guerre.
[^] # Re: Utilisation en production ?
Posté par Kaane . En réponse à la dépêche Et si la meilleure des cartes RAID était libre ?. Évalué à 4.
Bah, le RAID "Hardware" est surtout du software mis dans un CPU même plus trop dédié + RAM dédié, donc tant qu'à faire autant que ce soit sur le CPU principal et profiter de la mutualisation non?
Le RAID "Hardware" avait une super réputaiton, mais de nos jours je le vois de plus en plus critiqué et je lis de plus en plus "prenez la gestion RAID de Linux".
Ca c'est vrai pour l'entrée de gamme qui prétend faire du raid mais qui délègue 80% du boulot à l'hôte.
Sur de la carte un peu plus costaud ca n'est plus vrai du tout, notamment au niveau des I/Os. Mais bon il faut compter entre 100€ et 200€ du canal pour avoir un produit convenable.
[^] # Re: dramatisation
Posté par Kaane . En réponse au journal L'apocalypse d'Internet?. Évalué à 3.
Et encore, même cela peut devenir impossible. Vu la direction que prennent les choses, dans moins de 10 ans, internet pour particulier ça ne sera que de la CONSULATION sur le port 80 et 443 (port tcp 80,443 SORTANT).
Il y aura toujours un hacker pour faire un tunnel basé sur le protocole multi-player de candy-truc.
Mais une fois de plus ca va concerner 0.01% de la population…
[^] # Re: dramatisation
Posté par Kaane . En réponse au journal L'apocalypse d'Internet?. Évalué à 9.
C'est possible techniquement ça ?
C'est bien entendu contournable. N'importe qui qui connait un peu le fonctionnement des VPN, Tunnels et autres redirections de ports et NAT transversal sera toujours plus ou moins capable de passer outre les limitations.
Ca fait 0,01% de la population internet qui peut accéder à ton contenu si elle en a le temps et l'envie.
Madame Michu ne saura même pas que tu existe.
[^] # Re: Précision
Posté par Kaane . En réponse au journal Le développeur de Poche menacé par la société Read It Later. Évalué à 8.
Par la magie de la loi française, je tiens à rappeler que la diffamation inclue la vérité.
Et c'est une excellente chose. La diffamation relève du mensonge avec intention de nuire à l'image. Et le mensonge n'est pas l'opposé de la vérité. Le mensonge est l'opposé de la véracité et l'opposé de la vérité est la fausseté.
Si on se trompe, on peut parfaitement dire la vérité en mentant. De même que l'on peut parfaitement sortir une quantité absolument abhérantes d'anneries impossibles à adosser à des faits tout en étant persuadé d'être totalement franc et impartial (là pas besoin d'exemple, vous êtes sur LinuxFR vous devriez pouvoir trouver tout seul).
Le mensonge par omission qui consiste à négliger de mentionner certains faits ou éléments important pour la compréhension de l'énnoncé est un procédé (malheureusement) courant.
[^] # Re: Et vous, êtes vous féministe ?
Posté par Kaane . En réponse au journal Le féminisme me gonfle. Évalué à 6.
Super le test… Dès le début double contre sens sur la notion d'égailté avec renvoi sur la déclaration universelle des droits de l'homme.
Oui tous les êtres humains naissent et demeurent libres et égaux en droit.
Non tous les êtres humains ne sont pas égaux.
Et tout ça n'a rien à voir avec le fait qu'un groupe d'individu puisse être déconsidéré simplement par rapport à son genotype.
[^] # Re: Oui
Posté par Kaane . En réponse au journal Projets Open Source, des vaches à lait ?. Évalué à 5.
Euh il suffit de voir si le paquet est arrivé au niveau de la VM ou pas …
Déjà non. Parce que une fois de plus le comportement d'un kernel dans un environnement VM n'est pas identique à celui d'un kernel (au niveau latence, I/O, cache, temps de réponse du pilote hardware); et ensuite même si s'était le cas il faut également vérifier que le paquet n'a pas été altéré ou dénaturé soit par le kernel hôte, soit par la couche émulation carte réseau, soit par le pilote virtualisé. C'est seulement en ayant vérifié tout cela que l'on peut commencer à se demander si oui ou non ce paquet présente un risque pour la machine. Comment s'assurer de tout ça ? En mettant des sondes. Problèmes : il faut maintenant s'assurer que les sondes n'altèrent pas et ne dénaturent pas le paquet réseau, qu'elles n'ont pas d'influence sur les I/O, le cache, le comportement du kernel hôte etc. Comment faire çà ? En mettant d'autres sondes qui … euh…
Le problème est exactement le même que celui du programme qui crashe systématiquement à l’exécution, sauf en mode debug ou il tourne comme une horloge.
enfin à t'écouter, théo c'est plus une maison qu'il a, c'est un hangar de 1500 m² avec 2 lignes 20 kv.
Je crois qu'il n'y a "que" 200 ou 300m² dédiés aux machines. Par contre 40kVA ca va être juste, déjà moi je fais sauter mes 36kVA parfois (en pur particulier hein).