Non repéré avant par les autres, donc moins critique pour les autres.
La première personne qui rencontre un bug n'est pas forcément la seule affectée. Le fait qu'un paquet bizarre fasse planter une couche ou une sécurité chez une seule personne implique très souvent qu'en étudiant le bug à fond on puisse créer des exploits qui marcheront chez beaucoup de monde.
Et si tu te débrouille bien, tu fais mumuse sur la couche 3 et au dessus, et tu fous toutes tes VMs dans un seul hyperviseur dédié au test sur un réseau purement interne à l'hyperviseur (donc aucun paquet risque de partir). Tu fais planter que ta VMs, et au pire du pire du pire, tu fait juste planter l'hyperviseur.
Et au final tu n'as pas testé ce que tu voulais tester.
Tester la résistance de la couche simulation réseau d'un hyperviseur c'est bien, mais c'est la couche OpenBSD native que tu veux tester. Dans le genre de tests que tu préconises il est impossible de savoir si c'est OpenBSD qui est en défaut ou si c'est l'émulation.
Le seul truc où les Vms ne conviennent pas c'est dans tout ce qui est gestion du matos.
Que ce soit au niveau des I/O, des latences, du comportement des paquets la version VM est très différente de la version hors VM. Bien entendu les deux sont compatibles l'une avec l'autre, mais même avec du matos dédié (c'est à dire que la VM a une exclusivité sur un port PCi et la carte réseau qui est branchée dessus) on a pas les mêmes comportement que ce soit au niveau TCP, réémissions de paquets, débit, mise en cache et j'en passe.
Mais j'ai comme un doute que openbsd a des machines avec chaque type de carte réseau, chaque type de carte mère
Pas chaque non, mais quand même franchement beaucoup, Théo a quasiment un exemplaire de chaque matériel supporté - ce qui veut dire qu'il peut construire une machine raisonnablement similaire si un bug critique est remonté. (Encore une autre raison de ne pas vouloir être hébergé ailleurs tiens.)
que les dits serveurs sont tous chez Theo, dans sa cave, pour divers questions de sécurité.
Raisons de sécurité mais pas que, voire même pas prioritairement. Theo avait expliqué dans une conférence il y a un moment (hop là petite excuse pour dire, j'ai cherché sur le net, j'ai pas retrouvé) que le fait de disposer de sa propre infrastructure lui permettait d'effectuer un bon nombre de tests qui sont difficilement réalisables sur des infrastructures tiers, à fortiori des infrastructures de gens qui gagnent leur vie avec.
Des trucs comme "je vais faire des broadcasts DHCP pourri en mode hammer"(1) ou encore "C'est parti pour deux heures de TCP fuzzing"(2) ce sont des choses que les hébergeurs pro (ou même les hébergeurs à but non lucratif mais avec quand même des accords à respecter) n’apprécient pas. En d'autres termes, a moins de pouvoir dédier complètement une branche indépendante de l'infrastructure, les risques de faire tomber tout le système en accueillant les serveurs OpenBSD chez soi sont loin d'être nuls. Et Théo craint tout simplement qu'à la deuxième ou troisième fois ou les tests réseaux assez particuliers qu'il lance plantent le cœur, on le prie gentiment de prendre ses cliques et ses claques et d'aller voir ailleurs.
(1) Technique qui consiste (entre autre) à tenter de renouveler des baux DHCP que l'on a pas instauré. Très pratique pour les attaques man in the middle
(2) Comme pour le code fuzzing, on envoie sur le réseau moult paquets TCP conforme à la norme, mais avec un contenu aléatoire. Vous seriez surpris du nombre de switchs et de routeurs (y compris de grande marque) qui tombent en quelques minutes maximum quand on commence à jouer à ça.
Même sans être paranoïque, rien ne me choque dans mon imaginaire : c'est basique pour des services d'espionnage, juste des méthodes qui ont évolué avec la technologie.
Les services d'espionage dans mon imaginaire personnel c'était James Bond et Mata Hari.
Big Brother je rangeais ça dans la case Totalitarisme et controle des populations.
C'est toujours un bon point ça? Après l'abandon de Thunderbird et le succès fulgurant de XUL?
C'est au moins une garantie qu'on a accès aux sources et que l'on peut forker (moyennant un changement de nom éventuellement), c'est aussi une garantie de quasi absence d'agenda autre que "rendre le web plus accessible" - et traditionellement ils sont plutôt ouvert aux devs extérieurs.
Oui, parceque la partie bytecode de asm.js quand elle est compilée avec les optimisation AOT fait référence à une autre VM (enfin un chemin tellement différent dans la VM que l'on pourrait séparer les deux - si d'ailleurs asm.js a du succès il est probable que c’est ce qui se passera)
Alors que asm.js est lui même 100% compatible javascript.
Et si on te propose les 2 : les perfs ET sans compilation ?
En fait les choix sont plutôt
coté asm.js les bons points : Mozilla + perf + comptabilité avec l'existant + nombreuses preuves de ce qui a été fait (je pense notamment à la démo banana bread optimisée et à la démo Epic citadel). Avec en défaut : langage pénible à écrire (même en passant par LLJS c'est pas top) chaine de compilation compliquée à mettre en place (ca devrait s'arranger très vite si le langage a du succès)
et coté dart les bons points : perf + langage relativement agréable à écrire + pas de chaine de compilation à mettre en place (donc test et debug grandement accéléré); et en mauvais mauvais points : double rupture avec l'existant (Non seulement il faut implémenter Dart dans les nouveaux navigateurs pour en tirer parti, mais en plus toutes les étapes de manipulation DOM et events sont à réapprendre), google (on sait ce qui se passe quand une techno google a le succès escompté, on sait aussi ce qui se passe quand elle ne l'a pas), pas d'exemple "real life" (les exemple donnés sont pour le moins simplistes, pas moyen de trouver de "gros" exemple sur le web).
Les deux ont des avantages et des défauts, masi j'aurais plus tendance à croire en asm.js qu'en dart.
Il y a autant de similitudes entre asm.js et Dart qu'entre le bytecode de la JVM et le langage Java.
Non, asm.js est un langage. Il est quasiment impossible de l'écrire à la main certes, mais il s'agit ni plus ni moins que d'un subset de javascript. Le fait que la traduction se fasse systématiquement en bytecode est liée au fait que l'écriture manuelle de asm.js est pénible (pour rester poli) mais lljs résoud en grande partie ce problème en fournissant un autre langage facile à écrire et qui enlève le coté "magique" de la compilation de C/C++ en bytecode optimisé.
asm.js a pour but de permettre la compilation sous forme de bytecode javascript optimisé, de façon à pouvoir faire de l'AOT. Personne n'écrit de code directement en asm.js (à part les personne qui font asm.js bien sur) mais c'est techniquement faisable.
Après reste le problème de la compilation mentionné dans ton ancien post, mais bon c'est un faux problème - pour un gain de perf d'un facteur de l'ordre de 10 je n'ai rien contre lancer une compilation pour tester.
asm.js c'est mieux !
Rien à voir, asm.js est un sous-ensemble de JavaScript, une sorte de bytecode ou langage assembleur. Cela permet de convertir du C/C++ vers du JavaScript.
Les incompréhensions sur asm.js ont la vie dure.
asm.js est effectivement un sous ensemble de javascript, mais un sous ensemble qui est facile à compiler en bloc.
De la même façon que llvm est capable de convertir du C ou du C++ en bytecode javascript, il existe la possibilité de convertir le même C ou C++ en asm.js.
Cet code asm.js peut être éxecuté par n'importe quelle VM javascript (il s'agit de bytecode javascript complètement valide), mais si il est exécuté sur une VM qui connait asm.js il va pouvoir être compilé de façon beaucoup plus efficace - notamment parceque les optimisation AOT (ahead of time - c'est à dire la compilation à l'avance de morceaux dont on va forcément avoir besoin, par opposition au JIT (just in time) qui ne compile que quand il y a le besoin ). On a entre 1,4x et 3x la vitesse d’exécution du C++ avec le backend LLVM actuel - qui est loin d'être optimal aux dires des mainteneurs.
Dans ce sens il est complètement sur le même ségment que DART : un nouveau langage web destiné à être beaucoup plus facile et efficace à compiler en JIT (voire en compil classique) - Mais lui il ne casse pas tout l'existant pour ce faire. Cependant il ne faut pas non plus s'attendre à ce qu'il soit aussi performant que DART - du moins dans un premier temps. Cependant le but du jeu étant d'utiliser un maximum d'UI et de graphismes 2D/3D (la majorité du calcul étant fait coté serveur et/ou par la carte graphique pour la 3D) il est possible que l'approche asm.js soit suffisante pour 95% des apps.
Il est difficile d'écrire de l'asm.js directement à la mano sans passer par un pré-compiler, la façon la plus proche est d'utiliser http://mbebenita.github.io/LLJS/ LLJS qui rend les choses compréhensibles (même si une personne habitué au javascript pur va prendre un moment pour retrouver ses marques).
En ce qui concerne DART, les deux derniers projets Open Source de chez Google auxquels j'ai participé (Android et Wave) m'ont laissé un gout beaucoup trop amer pour que je ne le considère sérieusement. Malheureusement je ne suis pas le seul. Je considère l'approche asm.js/LLJS beaucoup plus claire, ouverte et viable.
C'est même gênant de gracier seulement Turing en oubliant les autres condamnés du fait de cette loi inique.
C'est tout le problème que posent les demandes en grâce faites par un lord à la reine. Ça suit tout un protocole à l'issue duquel la reine doit soit accorder la grâce soit la refuser. J'imagine qu'il doit aussi y avoir moyen de faire pression sur le lord pour que la demande soit retirée. On a donc un éventail de trois solutions à la con :
1) La famille royale fait pression sur lord Truc pour qu'il retire sa demande en grâce pour Alan Turing
2) La reine Elisabeth II refuse la grâce à Alan Turing
3) La reine Elisabeth II accorde la grâce à Alan Turing
Dans toutes ces options il y en a une qui est quand même moins con que les deux autres. C'est le choix qu'a fait Elisabeth II
Mais de toutes les façons, personne ne sait ce que fait la Suisse, tout le monde se fout de savoir ou ils en sont technologiquement, ça n'interresse personne de savoir que son vrai nom est "Confédération Helvétique" et quand à savoir ou ça se trouve :
J'imagine dire que "attention, des logiciels comme haproxy et plein d'autres que je ne cite pas peuvent requérir un oneliner bash pour fonctionner", ça casse vachement moins la baraque.
Bof tu sais dire "Attention, sur un logiciel comme HAProxy, quand on le lance avec systemd, même en mode fork (ce qui est déjà pas top) on est quand même obligé de faire un wrapper pour le reload", ca me gêne moins que de voir mes arguments réduit à peau de chagrin par les propres infos que j'ai donnée et que je n'ai pas su lire.
Non, la tu parles de cgroups tout court, à aucun moment tu ne parles de selinux dans ta réponse.
Ca s'appelle donner un exemple. Ce qui est indiqué en plus par Par exemple pour les cgroups :
Pour se-linux les exemples seraient beaucoup plus longs et compliqués à expliquer (non pas fondamentalement, mais parcequ'il faudrait que je raconte ma vie sinon il y a encore des gens "qui savent mieux" qui viendraient m'expliquer comment faire autrement sans se-linux)
Maintenant grosso-modo l'idée générale est que si tu veux protéger ton service contre un restart intempestif même par un user même root (dans le mauvais domaine), ben systemd va péter un câble. Charge à toi donc de concilier les droits et les différents domaines d'une façon qui a) ne casse pas ta sécurité et b) ne casse pas systemd/ta distrib.
C'est lourd.
Il n'y a pas de wrapper pour lancer haproxy, ça lance direct le binaire :
personne n'a dit que systemd répond à tous les besoin maintenant.
et les seuls qui ne veulent pas sont ceux qui n'aiment pas le changement et veulent garder le "bohneur" de la maintenance pourrie de ce qui existe avant.
Là, il va falloir choisir un des deux. Soit les personnes qui ne veulent pas de systemd sont des connards passéistes réactionnaires aigris et mal informés, soit il reste encore de vraies bonnes raisons de s'inquiéter de l'impact de systemd sur l'administration de certains systèmes dans certaines situations particulières.
Tout ce que je demande c'est que la possibilité numéro ne soit pas ridiculisée systématiquement.
Pour caricaturer, il y a deux possibilités :
- soit systemd devient turing complet et on va se retrouver dans deux, trois, quatre ans dans le même bordel de maintenance des scripts d'init.
- soit systemd ne devient pas turing complet et il y aura des admins qui ne pourront plus faire leur système comme ils ont l'habitude et qui devront recréer, tester et migrer vers une nouvelle architecture logicielle (nouvelles logiques d'init, nouvelles policies, potentiellement nouveaux logiciels).
combien de logiciels à la HAProxy qui en plus va refuser de s'adapter?
Typiquement un cas à la con pour systemd : mettre HAProxy derrière un wrapper entraine une perte de perfs, sortir HAProxy de son mode "single process, event driven" entraine une perte de perfs, bidouiller avec un pseudo-wrappo-manager à la nginx entrainne une perte de perf.
Grosso-modo si HAProxy "s'adapte" à systemd, il devient un autre logiciel.
Tu bullshites ( comme d'hab sur certains sujets, donc je vais pas passer du temps à te répondre ). … Mais peut être que tu veux dire qu'il faut rajouter des autorisations quand on rajoute des fonctions
Non, je parle des cgroups et de selinux.. Par exemple pour les cgroups : si tu veux que deux services partagent le même cgroup, ou si tu veux que ton cgroup de tagging serve aussi à créer des limites, ou si tu veux avoir plusieurs cgroups sur un service ou des dizaines d'autres choses. En fait quand les cgroups ont été créés, certaines personnes ont eu l'idée (idiote je le reconnais aujourd'hui, mais à l'époque c'était difficile à voir) que ça pouvait servir à autre chose qu'à permettre à un système d'init qui serait écrit plusieurs années plus tard. Un des trucs fantatisque (pour un admin) était les hiérarchies, créer un cgroup "database" qui a la priorité partout, et un cgroup "frontend" qui n'a le droit d'utiliser qu'un seul CPU, à peine un peu de bande passante et de mémoire. Bref les trucs fondamentaux vont dans le cgroup "database" et les autres trucs vont dans le cgroup "frontend" - donc même si un crétin avec les droits roots lance une commande bouffeuse de ressources, la base de données aura toujours quoi qu'il arrive 80% des ressources réservées pour elle. C'est cool c'est génial c'est beau.
SAUF QUE - systemd va venir se servir du tagging des cgroups pour faire sa sauce, et la c'est le drame. Par exemple si j'ai l'habitude de faire des triplets apache/mysql/php en fastCGI et de les mettre dans le même cgroup pour limiter (par exemple) la consommation CPU dudit cgroups. Typique je lance 10 triplets AMP dans 10 cgroups AMP0, AMP1 … AMP9 qui déscendent tous de AMP_MASTER qui limite la consomation CPU à 25% MAX. Je vais pas rentrer dans les détails, mais pour faire un truc pareil avec systemd tu vas morfler. Une fois dans un cgroup un process ne peux pas en sortir, une fois un cgroup activé aucun process ne peut rentrer dedans. Et tu ne peux même plus utiliser le tagging pour suivre le lancement de tes process parce que systemd utilise le sien propre (et qu'un sous système ne peut se trouver à deux endroits d'une même hiérarchie bien sur).
Voilà typiquement un exemple d'utilisation de cgroups que systemd empêche de faire fonctionner. Et typiquement pour t'en sortir il faut repenser tes policies.
Oups, tu peut remplir un bug pour Fedora, car visiblement, la fedora 20 que j'ai a l'air de réussir à le lancer, et visiblement, ç'est un bug que ça marche.
Dans mon post j'explique clairement ce que je veux dire :
En cas de reload systemd va interpréter l'arrêt du logiciel comme une panne et va tenter de le relancer avec les paramètres qu'il a en mémoire et dans le scope qu'il juge bon. Moralité vous êtes bon pour écrire des wrappers à la pelle ou à ne plus jamais utiliser de restart (sur un proxy c'est très emmerdant).
Fedora a écrit un wrapper qui a son tour lance HAProxy - sinon c'est la guerre au moment des reloads.
et les seuls qui ne veulent pas sont ceux qui n'aiment pas le changement et veulent garder le "bohneur" de la maintenance pourrie de ce qui existe avant.
Euh…. Même si il y a énormément de trolls contre systemd, il y a des raisons parfaitement valides d'être contre. Le fait de ne pas vouloir autant de dépendances dans un système d'init est un point tout à fait valide. L'init c'est la première chose que va faire le système, si ca merde à ce moment là vous ne pouvez rien faire pour corriger le tir. Vouloir le garder aussi maigre que possible n'est pas fondamentalement idiot.
Ensuite à l'heure actuelle il existe un certains nombres de matériels que l'on ne peut (toujours) pas initialiser proprement avec systemd. Typiquement les matériels multi-étage. Par exemple si vous devez initialiser une architecture crossbar sur laquelle est posée un émulateur réseau matériel (grosse station sun typiquement) systemd ne verra pas les cartes réseaux au moment de l'initialisation du réseau, et quand il les verra enfin pleins de services se seront déjà vautrés parce qu'il aura voulu anticiper l'ouverture des ports sur des cartes qu'il ne connait que plus tard. Idem pour les pinpad, si vous avez besoin de taper un code sur un clavier externe (ie pas le clavier de la machine) pour débloquer votre disque dur, à l'heure actuelle vous ne disposez d'aucun moyen de booter avec systemd à l'heure actuelle.
Autre problème, systemd n'est pas turing complet et décide tout seul dans quel scope il se lance (essayez d'altérer les cgroups de lancement de systemd pour rire - surtout si c'est pour rajouter des restrictions en plus du taging). Mur assuré. Si vous avez déjà vos politiques cgroups et selinux, vous pouvez prier qu'elles soient compatibles avec systemd, parceque l'alternative est probablement de redéfinir des politiques à partir de 0… Certains logiciels (dont l'excellent HAProxy) ne peuvent tout simplement être lancés par systemd. En cas de reload systemd va interpréter l'arrêt du logiciel comme une panne et va tenter de le relancer avec les paramètres qu'il a en mémoire et dans le scope qu'il juge bon. Moralité vous êtes bon pour écrire des wrappers à la pelle ou à ne plus jamais utiliser de restart (sur un proxy c'est très emmerdant).
Mais le truc qui m'emmerde le plus personnellement ce sont les templates d'une pourritude rare. Avec sysVinit ou bsdinit il est très facile de faire un script qui va prendre en paramètre une flopée de commandes et/ou de variables et me démarrer un service en fonction de ces variables. Par exemple pour créer un réseau virtuel avec un dhcp sur un segment IP donnée dynamiquement ca me prend une demi ligne de code. Je n'ai pas encore trouvé comment faire ça avec systemd. Il faut créer un service à la volée, l'enregistrer puis l'initialiser , savoir dès le début si on compte le relancer ou pas (sinon il faut faire un script pour le désinscrire au cas ou). ca devient d'une complexité démentielle de créer dynamiquement trois VM et de les mettre en réseau.
Systemd a des idées géniales et de très bons cotés, mais dans le travail que je fais en ce moment il n'est pas adapté. Et par pas adapté je ne vaux par dire "j'ai pas envie de tout réécrire et d'apprendre systemd" je veux dire "Systemd m'empêche sciemment et volontairement de mettre en place les outils dont j'ai absolument besoin pour travailler".
Mon point de vue est le suivant : systemd rend la vie de 95% des gens plus facile dans 95% des cas, c'était aussi le cas d'internet explorer 5.0
Je suis d'accord dans le principe pour le 42, ça peut paraître étrange, mais ça a aussi ses avantages le castage implicite. Mais c'est aussi pour ça qu'il existe en PHP le triple égal qui prend en compte le type: "0042"==="00042" retourne false. Mais c'est comme tout langage, quand tu comprend la mécanique interne, c'est pas un soucis.
C'était un exemple gentil, on peut parler de null, de 0, de "" et de undefined si on veut être méchant. Avec des belles brochettes sur is_null et isset (déjà rien qu'à la façon dont l'un et l'autre s'écrivent on commence à pouffer). Après on peut se marrer avec des classes nulle ou des interfaces non définies. Tu rajoutes de la création de classe dynamique avec des noms en UTF-8 et c'est festival.
Les langues qui comptent en négatif :
Le langage texto ca fait -1 langue
Le java ca fait -2 langues
Le chti ca fait -3 langues
Le basque ca fait -10 langues.
Si vous dites "chocolatine" et/ou "poche plastique" vous ne pouvez pas compter le français dans les langues que vous parlez.
Quand aux personnes qui sont féministes, illes sont prié-e-s de ne pas compter le massacre à la tronçonneuse des usages comme une langue à part entière.
Apparemment, je n'ai pas assez mis de gras, je dois le faire en capitale également ?
Tu as du mal lire. Tu dis que ça prévient, que ça évite pas mal de choses. Sous entendu il en reste d'autres qu'il faut traiter différemment.
Ce que je dis moi, c'est qu'il existe des cas (de plus en plus courant avec le cloud et autres anneries) dans lesquels ca va au contraire générer les problèmes dont tu parles. Si tu avais écris "dans la plupart des cas ca évite les fuites de mémoire" mon post tel qu'il est écrit n'aurait eu aucun intérêt. Mais ce ne pas ce que tu as écris.
De plus, ce que tu dis n'est pas valable pour la plus part des serveurs qui servent beaucoup de clients. C'est bien pour quelques clients qui demandent des gros traitements.
Pas forcément. Ce n'est pas valable pour les serveurs qui ont beaucoup de clients dont l'immense majorité va demander des traitements très rapides et non critiques. (Ce qui est le cas des serveurs web et des proxy en effet). Mais dans tous les autres cas, ça se discute. Dès qu'il y a des semaphores ou des mutex qui s'en mêlent ça devient assez rapidement rentable d'allouer de la mémoire et de faire le traitement directement en RAM avec une structure connue que de prendre le temps de classer, de morceler, d'analyser - avec le reste des processus qui attendent que quelqu'un veuille bien enlever le lock.
Pour les serveurs, travailler par petits morceau, minimiser les allocations, ce sont de très très bonnes pratiques.
Personne ne dit le contraire, mais des fois tu n'as pas le choix. En plus ça n'est pas toujours vrai.
Déjà, si tu peux faire une opération en mémoire qui va aller vite, il ne faut surtout pas t'en priver. Donc faire un gros malloc et utiliser la méthode lente (avec étude par segment des données, tri du truc, traitement par lot etc.) seulement si le malloc échoue ça fait gagner un paquet de temps.
Ensuite certaine opérations (notamment les bitmap scan des bases de données, un gros map des familles, la décompression de certains formats d'image etc.) ne peuvent se faire facilement qu'en mémoire. Bon après il y a toujours des acrobaties - mais c'est en faisant les acrobaties que tu risques de te prendre des fuites de mémoires, une mauvaise maitrise de la mémoire utilisés et des DOS.
Très honnêtement la méthode qui consiste à tenter d'abord un calloc, puis en cas d'échec on tente le malloc, puis en cas d'échec on attend un peu et on retente un malloc et finalement on fait la méthode lente (ou on envoie un message utilisateur disant que là, c'est loupé), est parfaitement valide dans tout un tas de cas.
Après pour éviter que ca ne vire à la guerre nucléaire totale, il y a toujours les "limit" UNIX. Dans de nombreux cas c'est ça qui va faire filet de secours pour ton système (on est jamais à l'abri d'une fuite de mémoire à la con dans le programme d'à coté).
malloc n'échoue jamais en pratique sur un OS décent, ensuite si malloc échoue, c'est qu'on est dans la merde, le savoir change pas grand chose, à part faire printf("va acheter de la RAM\n");exit(42);
Virtualisation, big data et fuite de mémoire d'une appli tierce sont dans un bateau. Qui est dans un autre univers. Parallèle au tien apparament. Et très éloigné.
Sur mes serveurs j'ai plusieurs milliers de malloc qui ratent tous les jours. Je le vis très bien, mes applis aussi.
[^] # Re: Oui
Posté par Kaane . En réponse au journal Projets Open Source, des vaches à lait ?. Évalué à 6.
Non repéré avant par les autres, donc moins critique pour les autres.
La première personne qui rencontre un bug n'est pas forcément la seule affectée. Le fait qu'un paquet bizarre fasse planter une couche ou une sécurité chez une seule personne implique très souvent qu'en étudiant le bug à fond on puisse créer des exploits qui marcheront chez beaucoup de monde.
[^] # Re: Oui
Posté par Kaane . En réponse au journal Projets Open Source, des vaches à lait ?. Évalué à 10.
Et si tu te débrouille bien, tu fais mumuse sur la couche 3 et au dessus, et tu fous toutes tes VMs dans un seul hyperviseur dédié au test sur un réseau purement interne à l'hyperviseur (donc aucun paquet risque de partir). Tu fais planter que ta VMs, et au pire du pire du pire, tu fait juste planter l'hyperviseur.
Et au final tu n'as pas testé ce que tu voulais tester.
Tester la résistance de la couche simulation réseau d'un hyperviseur c'est bien, mais c'est la couche OpenBSD native que tu veux tester. Dans le genre de tests que tu préconises il est impossible de savoir si c'est OpenBSD qui est en défaut ou si c'est l'émulation.
Le seul truc où les Vms ne conviennent pas c'est dans tout ce qui est gestion du matos.
Que ce soit au niveau des I/O, des latences, du comportement des paquets la version VM est très différente de la version hors VM. Bien entendu les deux sont compatibles l'une avec l'autre, mais même avec du matos dédié (c'est à dire que la VM a une exclusivité sur un port PCi et la carte réseau qui est branchée dessus) on a pas les mêmes comportement que ce soit au niveau TCP, réémissions de paquets, débit, mise en cache et j'en passe.
Mais j'ai comme un doute que openbsd a des machines avec chaque type de carte réseau, chaque type de carte mère
Pas chaque non, mais quand même franchement beaucoup, Théo a quasiment un exemplaire de chaque matériel supporté - ce qui veut dire qu'il peut construire une machine raisonnablement similaire si un bug critique est remonté. (Encore une autre raison de ne pas vouloir être hébergé ailleurs tiens.)
[^] # Re: Oui
Posté par Kaane . En réponse au journal Projets Open Source, des vaches à lait ?. Évalué à 10.
que les dits serveurs sont tous chez Theo, dans sa cave, pour divers questions de sécurité.
Raisons de sécurité mais pas que, voire même pas prioritairement. Theo avait expliqué dans une conférence il y a un moment (hop là petite excuse pour dire, j'ai cherché sur le net, j'ai pas retrouvé) que le fait de disposer de sa propre infrastructure lui permettait d'effectuer un bon nombre de tests qui sont difficilement réalisables sur des infrastructures tiers, à fortiori des infrastructures de gens qui gagnent leur vie avec.
Des trucs comme "je vais faire des broadcasts DHCP pourri en mode hammer"(1) ou encore "C'est parti pour deux heures de TCP fuzzing"(2) ce sont des choses que les hébergeurs pro (ou même les hébergeurs à but non lucratif mais avec quand même des accords à respecter) n’apprécient pas. En d'autres termes, a moins de pouvoir dédier complètement une branche indépendante de l'infrastructure, les risques de faire tomber tout le système en accueillant les serveurs OpenBSD chez soi sont loin d'être nuls. Et Théo craint tout simplement qu'à la deuxième ou troisième fois ou les tests réseaux assez particuliers qu'il lance plantent le cœur, on le prie gentiment de prendre ses cliques et ses claques et d'aller voir ailleurs.
(1) Technique qui consiste (entre autre) à tenter de renouveler des baux DHCP que l'on a pas instauré. Très pratique pour les attaques man in the middle
(2) Comme pour le code fuzzing, on envoie sur le réseau moult paquets TCP conforme à la norme, mais avec un contenu aléatoire. Vous seriez surpris du nombre de switchs et de routeurs (y compris de grande marque) qui tombent en quelques minutes maximum quand on commence à jouer à ça.
[^] # Re: Nouvel éditeur
Posté par Kaane . En réponse au journal Nouvelle interface pour gedit. Évalué à 0.
PPA, ce fléau des informaticiens…
[^] # Re: Et on se foutait de notre gueule…
Posté par Kaane . En réponse au journal Badbios vous a plu? Vous allez aimer le catalogue NSA. Évalué à 10.
Même sans être paranoïque, rien ne me choque dans mon imaginaire : c'est basique pour des services d'espionnage, juste des méthodes qui ont évolué avec la technologie.
Les services d'espionage dans mon imaginaire personnel c'était James Bond et Mata Hari.
Big Brother je rangeais ça dans la case Totalitarisme et controle des populations.
On a tous des imaginations différentes.
[^] # Re: Serieux?
Posté par Kaane . En réponse au journal Badbios vous a plu? Vous allez aimer le catalogue NSA. Évalué à 10.
Franchement, j'ai presque l'impression que c'est un hoax.
C'est que les noms ont été très très bien choisis alors…
[^] # Re: Petite digression sur asm.js
Posté par Kaane . En réponse au journal Normalisation du langage Dart de Google par l'Ecma. Évalué à 2.
C'est toujours un bon point ça? Après l'abandon de Thunderbird et le succès fulgurant de XUL?
C'est au moins une garantie qu'on a accès aux sources et que l'on peut forker (moyennant un changement de nom éventuellement), c'est aussi une garantie de quasi absence d'agenda autre que "rendre le web plus accessible" - et traditionellement ils sont plutôt ouvert aux devs extérieurs.
J'aimerai pouvoir en dire autant de Google…
[^] # Re: Petite digression sur asm.js
Posté par Kaane . En réponse au journal Normalisation du langage Dart de Google par l'Ecma. Évalué à 4. Dernière modification le 30 décembre 2013 à 10:23.
C'est l'emploi du mot "bytecode" qui te choque ?
Oui, parceque la partie bytecode de asm.js quand elle est compilée avec les optimisation AOT fait référence à une autre VM (enfin un chemin tellement différent dans la VM que l'on pourrait séparer les deux - si d'ailleurs asm.js a du succès il est probable que c’est ce qui se passera)
Alors que asm.js est lui même 100% compatible javascript.
Et si on te propose les 2 : les perfs ET sans compilation ?
En fait les choix sont plutôt
coté asm.js les bons points : Mozilla + perf + comptabilité avec l'existant + nombreuses preuves de ce qui a été fait (je pense notamment à la démo banana bread optimisée et à la démo Epic citadel). Avec en défaut : langage pénible à écrire (même en passant par LLJS c'est pas top) chaine de compilation compliquée à mettre en place (ca devrait s'arranger très vite si le langage a du succès)
et coté dart les bons points : perf + langage relativement agréable à écrire + pas de chaine de compilation à mettre en place (donc test et debug grandement accéléré); et en mauvais mauvais points : double rupture avec l'existant (Non seulement il faut implémenter Dart dans les nouveaux navigateurs pour en tirer parti, mais en plus toutes les étapes de manipulation DOM et events sont à réapprendre), google (on sait ce qui se passe quand une techno google a le succès escompté, on sait aussi ce qui se passe quand elle ne l'a pas), pas d'exemple "real life" (les exemple donnés sont pour le moins simplistes, pas moyen de trouver de "gros" exemple sur le web).
Les deux ont des avantages et des défauts, masi j'aurais plus tendance à croire en asm.js qu'en dart.
[^] # Re: Petite digression sur asm.js
Posté par Kaane . En réponse au journal Normalisation du langage Dart de Google par l'Ecma. Évalué à 1.
Il y a autant de similitudes entre asm.js et Dart qu'entre le bytecode de la JVM et le langage Java.
Non, asm.js est un langage. Il est quasiment impossible de l'écrire à la main certes, mais il s'agit ni plus ni moins que d'un subset de javascript. Le fait que la traduction se fasse systématiquement en bytecode est liée au fait que l'écriture manuelle de asm.js est pénible (pour rester poli) mais lljs résoud en grande partie ce problème en fournissant un autre langage facile à écrire et qui enlève le coté "magique" de la compilation de C/C++ en bytecode optimisé.
asm.js a pour but de permettre la compilation sous forme de bytecode javascript optimisé, de façon à pouvoir faire de l'AOT. Personne n'écrit de code directement en asm.js (à part les personne qui font asm.js bien sur) mais c'est techniquement faisable.
Après reste le problème de la compilation mentionné dans ton ancien post, mais bon c'est un faux problème - pour un gain de perf d'un facteur de l'ordre de 10 je n'ai rien contre lancer une compilation pour tester.
# Petite digression sur asm.js
Posté par Kaane . En réponse au journal Normalisation du langage Dart de Google par l'Ecma. Évalué à 2.
Les incompréhensions sur asm.js ont la vie dure.
asm.js est effectivement un sous ensemble de javascript, mais un sous ensemble qui est facile à compiler en bloc.
De la même façon que llvm est capable de convertir du C ou du C++ en bytecode javascript, il existe la possibilité de convertir le même C ou C++ en asm.js.
Cet code asm.js peut être éxecuté par n'importe quelle VM javascript (il s'agit de bytecode javascript complètement valide), mais si il est exécuté sur une VM qui connait asm.js il va pouvoir être compilé de façon beaucoup plus efficace - notamment parceque les optimisation AOT (ahead of time - c'est à dire la compilation à l'avance de morceaux dont on va forcément avoir besoin, par opposition au JIT (just in time) qui ne compile que quand il y a le besoin ). On a entre 1,4x et 3x la vitesse d’exécution du C++ avec le backend LLVM actuel - qui est loin d'être optimal aux dires des mainteneurs.
Dans ce sens il est complètement sur le même ségment que DART : un nouveau langage web destiné à être beaucoup plus facile et efficace à compiler en JIT (voire en compil classique) - Mais lui il ne casse pas tout l'existant pour ce faire. Cependant il ne faut pas non plus s'attendre à ce qu'il soit aussi performant que DART - du moins dans un premier temps. Cependant le but du jeu étant d'utiliser un maximum d'UI et de graphismes 2D/3D (la majorité du calcul étant fait coté serveur et/ou par la carte graphique pour la 3D) il est possible que l'approche asm.js soit suffisante pour 95% des apps.
Il est difficile d'écrire de l'asm.js directement à la mano sans passer par un pré-compiler, la façon la plus proche est d'utiliser http://mbebenita.github.io/LLJS/ LLJS qui rend les choses compréhensibles (même si une personne habitué au javascript pur va prendre un moment pour retrouver ses marques).
En ce qui concerne DART, les deux derniers projets Open Source de chez Google auxquels j'ai participé (Android et Wave) m'ont laissé un gout beaucoup trop amer pour que je ne le considère sérieusement. Malheureusement je ne suis pas le seul. Je considère l'approche asm.js/LLJS beaucoup plus claire, ouverte et viable.
[^] # Re: C'est pas pour gâcher l'esprit de Noël, mais...
Posté par Kaane . En réponse au journal Alan Turing gracié.. Évalué à 4.
C'est même gênant de gracier seulement Turing en oubliant les autres condamnés du fait de cette loi inique.
C'est tout le problème que posent les demandes en grâce faites par un lord à la reine. Ça suit tout un protocole à l'issue duquel la reine doit soit accorder la grâce soit la refuser. J'imagine qu'il doit aussi y avoir moyen de faire pression sur le lord pour que la demande soit retirée. On a donc un éventail de trois solutions à la con :
1) La famille royale fait pression sur lord Truc pour qu'il retire sa demande en grâce pour Alan Turing
2) La reine Elisabeth II refuse la grâce à Alan Turing
3) La reine Elisabeth II accorde la grâce à Alan Turing
Dans toutes ces options il y en a une qui est quand même moins con que les deux autres. C'est le choix qu'a fait Elisabeth II
[^] # Re: 3 ou 2 machines européennes dans le top 10 ?
Posté par Kaane . En réponse à la dépêche Le Top 500 de novembre 2013. Évalué à 5.
Mais de toutes les façons, personne ne sait ce que fait la Suisse, tout le monde se fout de savoir ou ils en sont technologiquement, ça n'interresse personne de savoir que son vrai nom est "Confédération Helvétique" et quand à savoir ou ça se trouve :
http://www.riehle.org/humorous-takes/fun-photos/ch-according-to-cnn.html
[^] # Re: GNU/SystemD/Linux
Posté par Kaane . En réponse au journal Systemd va gagner une console système, un bootsplash et un login-screen. Évalué à 0.
J'imagine dire que "attention, des logiciels comme haproxy et plein d'autres que je ne cite pas peuvent requérir un oneliner bash pour fonctionner", ça casse vachement moins la baraque.
Bof tu sais dire "Attention, sur un logiciel comme HAProxy, quand on le lance avec systemd, même en mode fork (ce qui est déjà pas top) on est quand même obligé de faire un wrapper pour le reload", ca me gêne moins que de voir mes arguments réduit à peau de chagrin par les propres infos que j'ai donnée et que je n'ai pas su lire.
[^] # Re: GNU/SystemD/Linux
Posté par Kaane . En réponse au journal Systemd va gagner une console système, un bootsplash et un login-screen. Évalué à 2.
Ca s'appelle donner un exemple. Ce qui est indiqué en plus par Par exemple pour les cgroups :
Pour se-linux les exemples seraient beaucoup plus longs et compliqués à expliquer (non pas fondamentalement, mais parcequ'il faudrait que je raconte ma vie sinon il y a encore des gens "qui savent mieux" qui viendraient m'expliquer comment faire autrement sans se-linux)
Maintenant grosso-modo l'idée générale est que si tu veux protéger ton service contre un restart intempestif même par un user même root (dans le mauvais domaine), ben systemd va péter un câble. Charge à toi donc de concilier les droits et les différents domaines d'une façon qui a) ne casse pas ta sécurité et b) ne casse pas systemd/ta distrib.
C'est lourd.
Relis la ligne reload…
ExecReload=/bin/bash -c
[^] # Re: GNU/SystemD/Linux
Posté par Kaane . En réponse au journal Systemd va gagner une console système, un bootsplash et un login-screen. Évalué à 7.
personne n'a dit que systemd répond à tous les besoin maintenant.
et les seuls qui ne veulent pas sont ceux qui n'aiment pas le changement et veulent garder le "bohneur" de la maintenance pourrie de ce qui existe avant.
Là, il va falloir choisir un des deux. Soit les personnes qui ne veulent pas de systemd sont des connards passéistes réactionnaires aigris et mal informés, soit il reste encore de vraies bonnes raisons de s'inquiéter de l'impact de systemd sur l'administration de certains systèmes dans certaines situations particulières.
Tout ce que je demande c'est que la possibilité numéro ne soit pas ridiculisée systématiquement.
Pour caricaturer, il y a deux possibilités :
- soit systemd devient turing complet et on va se retrouver dans deux, trois, quatre ans dans le même bordel de maintenance des scripts d'init.
- soit systemd ne devient pas turing complet et il y aura des admins qui ne pourront plus faire leur système comme ils ont l'habitude et qui devront recréer, tester et migrer vers une nouvelle architecture logicielle (nouvelles logiques d'init, nouvelles policies, potentiellement nouveaux logiciels).
combien de logiciels à la HAProxy qui en plus va refuser de s'adapter?
Typiquement un cas à la con pour systemd : mettre HAProxy derrière un wrapper entraine une perte de perfs, sortir HAProxy de son mode "single process, event driven" entraine une perte de perfs, bidouiller avec un pseudo-wrappo-manager à la nginx entrainne une perte de perf.
Grosso-modo si HAProxy "s'adapte" à systemd, il devient un autre logiciel.
[^] # Re: GNU/SystemD/Linux
Posté par Kaane . En réponse au journal Systemd va gagner une console système, un bootsplash et un login-screen. Évalué à 3.
Tu bullshites ( comme d'hab sur certains sujets, donc je vais pas passer du temps à te répondre ). … Mais peut être que tu veux dire qu'il faut rajouter des autorisations quand on rajoute des fonctions
Non, je parle des cgroups et de selinux.. Par exemple pour les cgroups : si tu veux que deux services partagent le même cgroup, ou si tu veux que ton cgroup de tagging serve aussi à créer des limites, ou si tu veux avoir plusieurs cgroups sur un service ou des dizaines d'autres choses. En fait quand les cgroups ont été créés, certaines personnes ont eu l'idée (idiote je le reconnais aujourd'hui, mais à l'époque c'était difficile à voir) que ça pouvait servir à autre chose qu'à permettre à un système d'init qui serait écrit plusieurs années plus tard. Un des trucs fantatisque (pour un admin) était les hiérarchies, créer un cgroup "database" qui a la priorité partout, et un cgroup "frontend" qui n'a le droit d'utiliser qu'un seul CPU, à peine un peu de bande passante et de mémoire. Bref les trucs fondamentaux vont dans le cgroup "database" et les autres trucs vont dans le cgroup "frontend" - donc même si un crétin avec les droits roots lance une commande bouffeuse de ressources, la base de données aura toujours quoi qu'il arrive 80% des ressources réservées pour elle. C'est cool c'est génial c'est beau.
SAUF QUE - systemd va venir se servir du tagging des cgroups pour faire sa sauce, et la c'est le drame. Par exemple si j'ai l'habitude de faire des triplets apache/mysql/php en fastCGI et de les mettre dans le même cgroup pour limiter (par exemple) la consommation CPU dudit cgroups. Typique je lance 10 triplets AMP dans 10 cgroups AMP0, AMP1 … AMP9 qui déscendent tous de AMP_MASTER qui limite la consomation CPU à 25% MAX. Je vais pas rentrer dans les détails, mais pour faire un truc pareil avec systemd tu vas morfler. Une fois dans un cgroup un process ne peux pas en sortir, une fois un cgroup activé aucun process ne peut rentrer dedans. Et tu ne peux même plus utiliser le tagging pour suivre le lancement de tes process parce que systemd utilise le sien propre (et qu'un sous système ne peut se trouver à deux endroits d'une même hiérarchie bien sur).
Voilà typiquement un exemple d'utilisation de cgroups que systemd empêche de faire fonctionner. Et typiquement pour t'en sortir il faut repenser tes policies.
Oups, tu peut remplir un bug pour Fedora, car visiblement, la fedora 20 que j'ai a l'air de réussir à le lancer, et visiblement, ç'est un bug que ça marche.
Dans mon post j'explique clairement ce que je veux dire :
Fedora a écrit un wrapper qui a son tour lance HAProxy - sinon c'est la guerre au moment des reloads.
[^] # Re: GNU/SystemD/Linux
Posté par Kaane . En réponse au journal Systemd va gagner une console système, un bootsplash et un login-screen. Évalué à 10.
et les seuls qui ne veulent pas sont ceux qui n'aiment pas le changement et veulent garder le "bohneur" de la maintenance pourrie de ce qui existe avant.
Euh…. Même si il y a énormément de trolls contre systemd, il y a des raisons parfaitement valides d'être contre. Le fait de ne pas vouloir autant de dépendances dans un système d'init est un point tout à fait valide. L'init c'est la première chose que va faire le système, si ca merde à ce moment là vous ne pouvez rien faire pour corriger le tir. Vouloir le garder aussi maigre que possible n'est pas fondamentalement idiot.
Ensuite à l'heure actuelle il existe un certains nombres de matériels que l'on ne peut (toujours) pas initialiser proprement avec systemd. Typiquement les matériels multi-étage. Par exemple si vous devez initialiser une architecture crossbar sur laquelle est posée un émulateur réseau matériel (grosse station sun typiquement) systemd ne verra pas les cartes réseaux au moment de l'initialisation du réseau, et quand il les verra enfin pleins de services se seront déjà vautrés parce qu'il aura voulu anticiper l'ouverture des ports sur des cartes qu'il ne connait que plus tard. Idem pour les pinpad, si vous avez besoin de taper un code sur un clavier externe (ie pas le clavier de la machine) pour débloquer votre disque dur, à l'heure actuelle vous ne disposez d'aucun moyen de booter avec systemd à l'heure actuelle.
Autre problème, systemd n'est pas turing complet et décide tout seul dans quel scope il se lance (essayez d'altérer les cgroups de lancement de systemd pour rire - surtout si c'est pour rajouter des restrictions en plus du taging). Mur assuré. Si vous avez déjà vos politiques cgroups et selinux, vous pouvez prier qu'elles soient compatibles avec systemd, parceque l'alternative est probablement de redéfinir des politiques à partir de 0… Certains logiciels (dont l'excellent HAProxy) ne peuvent tout simplement être lancés par systemd. En cas de reload systemd va interpréter l'arrêt du logiciel comme une panne et va tenter de le relancer avec les paramètres qu'il a en mémoire et dans le scope qu'il juge bon. Moralité vous êtes bon pour écrire des wrappers à la pelle ou à ne plus jamais utiliser de restart (sur un proxy c'est très emmerdant).
Mais le truc qui m'emmerde le plus personnellement ce sont les templates d'une pourritude rare. Avec sysVinit ou bsdinit il est très facile de faire un script qui va prendre en paramètre une flopée de commandes et/ou de variables et me démarrer un service en fonction de ces variables. Par exemple pour créer un réseau virtuel avec un dhcp sur un segment IP donnée dynamiquement ca me prend une demi ligne de code. Je n'ai pas encore trouvé comment faire ça avec systemd. Il faut créer un service à la volée, l'enregistrer puis l'initialiser , savoir dès le début si on compte le relancer ou pas (sinon il faut faire un script pour le désinscrire au cas ou). ca devient d'une complexité démentielle de créer dynamiquement trois VM et de les mettre en réseau.
Systemd a des idées géniales et de très bons cotés, mais dans le travail que je fais en ce moment il n'est pas adapté. Et par pas adapté je ne vaux par dire "j'ai pas envie de tout réécrire et d'apprendre systemd" je veux dire "Systemd m'empêche sciemment et volontairement de mettre en place les outils dont j'ai absolument besoin pour travailler".
Mon point de vue est le suivant : systemd rend la vie de 95% des gens plus facile dans 95% des cas, c'était aussi le cas d'internet explorer 5.0
[^] # Re: GNU/SystemD/Linux
Posté par Kaane . En réponse au journal Systemd va gagner une console système, un bootsplash et un login-screen. Évalué à 1.
Le système d'init/boot, en temps que d'utilisateur et développeur, je n'ai que très rarement un contact direct avec.
Si tu as envie que ça reste comme ça, je te déconseille formellement systemd.
[^] # Re: Puisque l'on est vendredi…
Posté par Kaane . En réponse au journal Gnome 3.8 dans debian Jessie !. Évalué à 7.
Depuis quand, une version qui n'est pas la plus récente est-elle nécessairement obsolète ?
Depuis Gnome 3.2 à peu près…
[^] # Re: hint: PHP
Posté par Kaane . En réponse au journal Développeur, ou comment sur-évaluer ses compétences. Évalué à 10.
Je suis d'accord dans le principe pour le 42, ça peut paraître étrange, mais ça a aussi ses avantages le castage implicite. Mais c'est aussi pour ça qu'il existe en PHP le triple égal qui prend en compte le type: "0042"==="00042" retourne false. Mais c'est comme tout langage, quand tu comprend la mécanique interne, c'est pas un soucis.
C'était un exemple gentil, on peut parler de null, de 0, de "" et de undefined si on veut être méchant. Avec des belles brochettes sur is_null et isset (déjà rien qu'à la façon dont l'un et l'autre s'écrivent on commence à pouffer). Après on peut se marrer avec des classes nulle ou des interfaces non définies. Tu rajoutes de la création de classe dynamique avec des noms en UTF-8 et c'est festival.
# Pour ceux qui ne connaissent pas les barèmes en vigueur
Posté par Kaane . En réponse au sondage Êtes-vous polyglottes ?. Évalué à 10.
Les langues qui comptent en négatif :
Le langage texto ca fait -1 langue
Le java ca fait -2 langues
Le chti ca fait -3 langues
Le basque ca fait -10 langues.
Si vous dites "chocolatine" et/ou "poche plastique" vous ne pouvez pas compter le français dans les langues que vous parlez.
Quand aux personnes qui sont féministes, illes sont prié-e-s de ne pas compter le massacre à la tronçonneuse des usages comme une langue à part entière.
Merci de votre attention.
[^] # Re: Pauvreté de l'offre européenne
Posté par Kaane . En réponse à la dépêche Préoccupés par ce qu'on ne peut pas vous dire ? Nous aussi (Google Transparency Report). Évalué à 4.
Faut-il mettre attention c'est complexe et pas pour tout le monde devant chaque message sur linuxfr.org?
Vu le prosélitisme "un peu" optimiste de Tanguy Ortolo sur le sujet, quand on parle d'auto-hébergement il vaut mieux oui.
[^] # Re: Laissez malloc tranquille !
Posté par Kaane . En réponse à la dépêche Le langage Go fête ses 4 ans. Évalué à 3.
Apparemment, je n'ai pas assez mis de gras, je dois le faire en capitale également ?
Tu as du mal lire. Tu dis que ça prévient, que ça évite pas mal de choses. Sous entendu il en reste d'autres qu'il faut traiter différemment.
Ce que je dis moi, c'est qu'il existe des cas (de plus en plus courant avec le cloud et autres anneries) dans lesquels ca va au contraire générer les problèmes dont tu parles. Si tu avais écris "dans la plupart des cas ca évite les fuites de mémoire" mon post tel qu'il est écrit n'aurait eu aucun intérêt. Mais ce ne pas ce que tu as écris.
De plus, ce que tu dis n'est pas valable pour la plus part des serveurs qui servent beaucoup de clients. C'est bien pour quelques clients qui demandent des gros traitements.
Pas forcément. Ce n'est pas valable pour les serveurs qui ont beaucoup de clients dont l'immense majorité va demander des traitements très rapides et non critiques. (Ce qui est le cas des serveurs web et des proxy en effet). Mais dans tous les autres cas, ça se discute. Dès qu'il y a des semaphores ou des mutex qui s'en mêlent ça devient assez rapidement rentable d'allouer de la mémoire et de faire le traitement directement en RAM avec une structure connue que de prendre le temps de classer, de morceler, d'analyser - avec le reste des processus qui attendent que quelqu'un veuille bien enlever le lock.
[^] # Re: Laissez malloc tranquille !
Posté par Kaane . En réponse à la dépêche Le langage Go fête ses 4 ans. Évalué à 4.
Pour les serveurs, travailler par petits morceau, minimiser les allocations, ce sont de très très bonnes pratiques.
Personne ne dit le contraire, mais des fois tu n'as pas le choix. En plus ça n'est pas toujours vrai.
Déjà, si tu peux faire une opération en mémoire qui va aller vite, il ne faut surtout pas t'en priver. Donc faire un gros malloc et utiliser la méthode lente (avec étude par segment des données, tri du truc, traitement par lot etc.) seulement si le malloc échoue ça fait gagner un paquet de temps.
Ensuite certaine opérations (notamment les bitmap scan des bases de données, un gros map des familles, la décompression de certains formats d'image etc.) ne peuvent se faire facilement qu'en mémoire. Bon après il y a toujours des acrobaties - mais c'est en faisant les acrobaties que tu risques de te prendre des fuites de mémoires, une mauvaise maitrise de la mémoire utilisés et des DOS.
Très honnêtement la méthode qui consiste à tenter d'abord un calloc, puis en cas d'échec on tente le malloc, puis en cas d'échec on attend un peu et on retente un malloc et finalement on fait la méthode lente (ou on envoie un message utilisateur disant que là, c'est loupé), est parfaitement valide dans tout un tas de cas.
Après pour éviter que ca ne vire à la guerre nucléaire totale, il y a toujours les "limit" UNIX. Dans de nombreux cas c'est ça qui va faire filet de secours pour ton système (on est jamais à l'abri d'une fuite de mémoire à la con dans le programme d'à coté).
[^] # Re: Laissez malloc tranquille !
Posté par Kaane . En réponse à la dépêche Le langage Go fête ses 4 ans. Évalué à 10.
malloc n'échoue jamais en pratique sur un OS décent, ensuite si malloc échoue, c'est qu'on est dans la merde, le savoir change pas grand chose, à part faire printf("va acheter de la RAM\n");exit(42);
Virtualisation, big data et fuite de mémoire d'une appli tierce sont dans un bateau. Qui est dans un autre univers. Parallèle au tien apparament. Et très éloigné.
Sur mes serveurs j'ai plusieurs milliers de malloc qui ratent tous les jours. Je le vis très bien, mes applis aussi.