Linux? - Page 131

GoldenCrystal (./3896) :
Exact, c'est pas là que partirait l'essentiel de l'argent si on distribuait N'importe quel système d'exploitation gratuit basé sur GNU/Linux, approuvé par la FSF et béni par Saint RMS™. Est-tu capable de déterminer les nombreuses autres étapes que tu as oublié dans le processus et de déduire par toi même où sont les nombreux coûts "cachés" qui interviennent dans une telle opération ?

Quels coûts cachés? Le FUD du TCO (total cost of ownership) est déjà limite quand il s'agit du choix des logiciels dans les entreprises, mais là ce n'est pas du tout pertinent. Le producteur du matériel n'a aucune obligation autre que d'installer le système préinstallé.

Deux constructeurs, deux PC, mêmes composants. L'un est moins cher et proposé nu sans OS. L'autre est plus cher de quelques dizaines d'euros et proposé avec un système utilisable à la sortie de la boîte.Devine lequel se vendra le mieux ?

Normalement, c'est le premier qui devrait se vendre mieux, étant donné qu'il y a Fedora, Debian, Ubuntu etc. disponibles gratuitement. (Il n'y a que l'embarras du choix.) Ce n'est que l'ignorance qui pousse les gens à préférer le deuxième. (Personnellement, j'achèterais le premier sans hésiter, évidemment.)

En gros un truc qui rend l'espace mémoire de tous les processus fils identiques (bye bye ASLR !) et bien plus vulnérables à une attaque, quoi…
Et on parle de sécurité…

Il y a toujours un ASLR, juste pas pour chaque exécution. C'est d'ailleurs la même chose avec prelink qui est utilisé d'office dans Fedora (qui ne fonctionne pas à travers fork(), mais en prérelogeant les objets sur disque), et d'ailleurs, kdeinit désactive le "hack kdeinit" quand prelink est utilisé parce que le gain de performance que le hack permet d'obtenir est beaucoup moins important quand on utilise prelink (qui réduit déjà de beaucoup le coût du chargement).

Ben si, t'as qu'à regarder le code d'un hello world quelconque, une grande partie sont exempts de bugs.

Tu n'as pas l'air de comprendre le sens de l'expression "en pratique".

Zerosquare (./3900) :
Tu n'a pas besoin de lancer un nouveau processus pour chaque requête, tu peux avoir un pool de processus déjà lancés et leur transmettre la requête quand elle arrive. Ça se fait aussi avec les threads d'ailleurs.

(en référence au ./3890) Oui, mais justement, ça se fait avec fork(). Les processus déjà lancés sont tous en accept() sur le même socket, hérité via fork. Tu as besoin de fork pour faire ça avec des processus.

Sinon c'est une bonne question le temps de linking. Il y a beaucoup de symboles quand même dans les libs objet. Des quelques références qu'on trouve sur le sujet, sur les systèmes à base de GCC récent et binutils disposant de -DT_GNU_HASH c'est plus tellement utile, mais sur d'autres systèmes ça reste un gain de temps significatif (FreeBSD par exemple).

spectras (./3897) :
D'ailleurs, l'idée que la création d'un processus est une opération coûteuse est peut-être vraie sous windows (justement parce que ça passe par CreateProcess qui doit en créer un de toutes pièces), mais un fork() est presque aussi rapide qu'un pthread_create.

C'est clair, mais si tout ce qu'on connaît est le fork() de Cygwin (qui utilise un paquet de hacks qui rament à fond, probablement par dessus CreateProcess), on ne peut pas comprendre cela.

D'ailleurs, OS X, qui se veut un UNIX™, n'a même pas une implémentation complète de fork(). Pour la certification, ils se sont appuyés sur une clause du standard qui permet d'émuler fork() par vfork() ou quelque chose qui ressemble (qui ne permet pas de faire grand chose à part un exec), prévue normalement pour les *nix embarqués sur des systèmes sans MMU (ou un fork() complet n'est pas possible). Il n'y a aucune raison valable de ne pas proposer un fork() complet sous OS X!

./3897 > Pour les histoires d'identité/de droits, le coup de impersonate ne te va pas ?
./3898 > Ouais mais ça fait partie des trucs tiers ça
./3899 > Tu mettrais quoi comme gestion d'erreur dans un int main(int argc, char** args) { printf("Hello World\n"); return 0; } ? (Et ouais c'est hors sujet, mais je fais preuve de démarche scientifique pour trouver un exemple pratique à Kevin qui dit que du code sans bug n'existe pas en pratique )
./3900 > Il me semble que la création de processus est assez optimisée sur Windows. (Enfin sous Windows Vista/7/8 au moins, parce que Windows XP je le trouve assez mou dans ce domaine)
Typiquement, au moins pour certaines DLL, l'adresse de base est déterminée au premier chargement de la DLL, et les mêmes pages sont recopiées dans tous les processus les utilisant…
Il y a aussi le prefetcher qui doit aider pas mal au démarrage des applications, et le cache mémoire qui sert pour le démarrage à chaud si la mémoire n'est pas saturée…

Dans la pratique en fait, ça doit être assez proche de ce que fait kdeinit, si je comprends bien, à la différence que l'espace mémoire sera plus aléatoire. (Le heap ne se situera pas forcément au même endroit dans deux processus d'apparence identiques…)

GoldenCrystal (./3904) :
./3899 > Tu mettrais quoi comme gestion d'erreur dans un int main(int argc, char** args) { printf("Hello World\n"); return 0; } ? (Et ouais c'est hors sujet, mais je fais preuve de démarche scientifique pour trouver un exemple pratique à Kevin qui dit que du code sans bug n'existe pas en pratique )

Un Hello World n'est pas un code pratique, c'est un code jouet sans intérêt.

Et puis il manque le #include <stdio.h> (Les déclarations implicites sont dépréciées et très dangereuses!) et la gestion de la valeur de retour de printf (qui peut échouer si stdout est redirigé par exemple sur un fichier sur NFS et le réseau saute pile à ce moment) dans ton code.

spectras (./3903) :
Oui, mais justement, ça se fait avec fork(). Les processus déjà lancés sont tous en accept() sur le même socket, hérité via fork. Tu as besoin de fork pour faire ça avec des processus.

Sous Linux oui, mais tu peux faire la même chose sous Windows aussi en utilisant des handles héritables.

fork() n'est pas un élément indispensable, c'est un choix qui a été fait par UNIX il y a longtemps, et j'ai toujours ça trouvé bizarre d'avoir implémenté fork() bien avant les threads, qui sont quelque chose de conceptuellement plus simple.

spectras (./3902) :
Oui, mais justement, ça se fait avec fork(). Les processus déjà lancés sont tous en accept() sur le même socket, hérité via fork. Tu as besoin de fork pour faire ça avec des processus.

Un processus enfant peut parfaitement hériter des handles de son papa.
Voir la page de MSDN sur le sujet pour ceux qui ne sont pas au courant
C'est très souple comme système, faut pas croire.

Windows ne propose pas fork (parce que ça ne sert à rien ) mais c'est par pour ça qu'il a une gestion pourrie des processus
(Après y'a quand même des trucs assez obscurs comme le fait que l'arborescence des processus soit connue mais masquée… ^^)

./3903 > Bah, qui sait… Peut-être qu'ils ont estimé que fork ne sert à rien…
Et hello world est un code pratique ! Ça permet de montrer un code qui fonctonne en introduction à un langage ! (Bon perso j'ai toujours trouvé ça con, mais chut)

Mais tout ça nous éloigne du sujet des "racketticiels" !

Zerosquare (./3906) :
fork() n'est pas un élément indispensable, c'est un choix qui a été fait par UNIX il y a longtemps, et j'ai toujours ça trouvé bizarre d'avoir implémenté fork() bien avant les threads, qui sont quelque chose de conceptuellement plus simple.

C'est parce que fork() est indispensable pour lancer un processus dans l'API POSIX, vu comment fonctionnent exec*().

Bien sûr, on aurait pu implémenter spawn*() à la place de fork() et exec*(), mais à ma connaissance, ces fonctions n'ont été introduites que plus tard et sont implémentées dans la libc en fonction des syscalls fork() + exec*().

Mais POSIX date de bien après UNIX, donc ce sont les choix d'UNIX qui ont influencé POSIX.

GoldenCrystal (./3904) :
./3897 > Pour les histoires d'identité/de droits, le coup de impersonate ne te va pas ?

Si.
Même si du coup c'est pas super l'isolation si t'as un thread de toto qui peut accéder à la mémoire du thread de Administrator.

GoldenCrystal (./3904) :
./3899 > Tu mettrais quoi comme gestion d'erreur dans un int main(int argc, char** args) { printf("Hello World\n"); return 0; } ? (Et ouais c'est hors sujet, mais je fais preuve de démarche scientifique pour trouver un exemple pratique à Kevin qui dit que du code sans bug n'existe pas en pratique )

Eh bien, par exemple, que la fonction printf peut échouer.
« If an output error is encountered, a negative value is returned. »
Auquel cas, la moindre des choses serait de quitter le programme avec un code d'erreur.
Comme quoi, même avec la meilleure volonté du monde sur un programme qui parait trivial on peut oublier de gérer des erreurs.
Maintenant, autre exercice similaire, le même en C++ en gérant toutes les exceptions susceptibles d'être levées. C'est un exercice intéressant, et ça permet de réaliser à quel point on peut sous-estimer le nombre de causes d'erreur.

Sinon oui c'est une autre approche, mais ça semble tendre au même objectif. A noter que les DLL ont toujours été moins coûteuses en linkage dynamique, parce qu'elles sont référencées par un numéro et pas par un symbole (le prog dit je veux la fonction n°3, 4 et 8 de la dll). C'est plus rapide, par contre ça part en segfault quand la version n'est pas bonne, vu que ça n'appelle pas les bonnes fonctions (on n'est pas à l'abri que les numéros des fonctions changent à chaque recompilation). C'est particulièrement dommage quand on sait que windows ne permet pas la cohabitation de plusieurs version d'une même DLL.
Mais bon, c'est quelque chose qu'on ne touche plus tellement ces jours ci, avec .NET.

GoldenCrystal (./3907) :
Un processus enfant peut parfaitement hériter des handles de son papa.
Voir la page de MSDN sur le sujet pour ceux qui ne sont pas au courant

Et ça fait partie des bidouilles du fork() de Cygwin.

C'est très souple comme système, faut pas croire.

Bah non, ce n'est pas assez souple, il manque le copy-on-write de la mémoire!

./3903 > Bah, qui sait… Peut-être qu'ils ont estimé que fork ne sert à rien…

Ça montre surtout que la "compatibilité UNIX" de OS X n'est qu'un gag marketing et qu'ils n'ont strictement rien à battre de la compatibilité pratique. Plusieurs programmes ont des bidouilles pour ne pas utiliser fork() sous OS X parce que ça ne marche pas.

Et hello world est un code pratique ! Ça permet de montrer un code qui fonctonne en introduction à un langage ! (Bon perso j'ai toujours trouvé ça con, mais chut)

Mais tout ça nous éloigne du sujet des "racketticiels" !

C'est toi qui as lancé la guerre des APIs.

Zerosquare (./3909) :
Mais POSIX date de bien après UNIX, donc ce sont les choix d'UNIX qui ont influencé POSIX.

C'est clair, évidemment! Donc reformulons:
C'est parce que fork() est indispensable pour lancer un processus dans l'API de AT&T UNIX et de tout ce qui suit, vu comment fonctionnent exec*().

je ne connais pas grand chose à la prog système avec de multiples process et thread mais je peut vous donner un exemple ou fork est indispensable, redis

cette base met tout en ram, elle peut prendre 10 giga sans soucis

pour assurer la persistance celle ci se dumpe intégralement (ou non, mais prenons le cas intégral ici) sur le disque

cette opération peu prendre du temps, mais le but de redis est d'être rapide, très rapide, donc la base doit être dispo (et pas en lecture seule) durant le dump

bref, elle doit avoir un shoot propre à dumper, qui ne va pas non plus se modifier durant ce dump, et on ne va pas dupliquer 10GB de ram, bref redis forke, le process forké fait son dump pendant que l'original lui continu à servir les clients et modifier si il le faut sa version

une explication ici http://redis.io/topics/faq

alors soit on laisse linux faire sa magie, le code de redis restant simple et efficace, soit on modifie redis en profondeur pour qu'il puisse à la fois dumper et servir en même temps, c'est ce qu'on fait des gars de chez microsoft

Excellent exemple de comment fork() est beaucoup plus souple (tout en étant beaucoup plus simple) que CreateProcess.

GoldenCrystal (./3907) :
Un processus enfant peut parfaitement hériter des handles de son papa.
Voir la page de MSDN sur le sujet pour ceux qui ne sont pas au courant C'est très souple comme système, faut pas croire.

Sauf que… sauf que… les sockets ne sont pas héritables. C'est écrit dans la documentation en toutes lettres.
C'est même écrit d'une manière très amusante. Je cite :

You should not use DuplicateHandle to duplicate handles to the following objects:
— I/O completion ports. No error is returned, but the duplicate handle cannot be used.
— Sockets. No error is returned, but the duplicate handle may not be recognized by Winsock at the target process. Also, using DuplicateHandle interferes with internal reference counting on the underlying object.

WTF?!!!?
Donc la fonction ne retourne pas d'erreur, mais n'a pas fait son boulot. Pire, elle risque de provoquer une fuite de ressources dans les libs systèmes. Are you f*cking kidding me?

Enfin bref, tout ça pour dire que non, on ne peut pas utiliser createprocess pour partager un socket. Mais il y a même un truc encore plus rigolo : bien que non héritables, ils sont parfois hérités quand même, même s'ils ont été marqués NON héritables.

(à cas où tu te poserais la question l'usage de SetHandleInformation au lieu de DuplicateHandle arrive au même résultat : des fois ça marche, des fois ça marche pas. C'est logique quelque part vu que c'est le même mécanisme sous-jacent. Sauf que pour SetHandleInformation c'est même pas écrit dans la doc qu'il ne faut pas l'utiliser sur des sockets — et WSADuplicateSocket ne permet pas de changer l'attribut inheritable).

Tu vois le souci des apis w32, c'est que dès que tu fais quoi que ce soit, tu te manges ce genre de trucs. Comportement incohérent (on peut dupliquer certains handles mais pas tous, c'est quoi l'intérêt de l'abstraction en handles alors), voire comportement aléatoire. T'apprends à naviguer autour, mais l'ensemble est très inconsistant, ce qui fait perdre du temps (il faut toujours vérifier chaque ligne de la doc à chaque fois que tu fais quelque chose), et fait faire des erreurs. La preuve, jusqu'à il y a 2 minutes, bien que tu sois un développeur aguéri, tu pensais pouvoir hériter n'importe quel handle.

Jeu, set et match

spectras (./3910) :
Maintenant, autre exercice similaire, le même en C++ en gérant toutes les exceptions susceptibles d'être levées.

J'ai jamais trouvé un source C++ qui gérait bien les erreurs, même dans les tutos. Dès qu'on utilise un pet de la SDL, faudrait s'y intéresser, c'est quasiment jamais fait ^^

Kevin Kofler (./3911) :
Ça montre surtout que la "compatibilité UNIX" de OS X n'est qu'un gag marketing et qu'ils n'ont strictement rien à battre de la compatibilité pratique. Plusieurs programmes ont des bidouilles pour ne pas utiliser fork() sous OS X parce que ça ne marche pas.

Bin les logiciels en question n'ont qu'à respecter la norme POSIX

Ce qu'il y a bien avec toi, c'est que tu considères que le standard à respecter est ce qui est ni un standard officiel (ISO), ni un truc utilisé sur la majorité des machines, mais bien un truc qui utilisé sur 1% des machines...

./3910 > Ouais, éventuellement on peut faire retourner un code d'erreur au programme hello world, mais bon…
Pour le reste, est-ce tu penses que gérer toutes les erreurs (donc pas gérer "n'importe quelle erreur") y compris celles qui ne sont pas sensées arriver est vraiment une bonne pratique ? Personnellement je ne suis pas de cet avis. (Après, c'est le problème que j'ai avec les codes d'erreur en retour de méthode, c'est trop facile à ignorer à l'inverse des exceptions…)

./3913 > Ouais enfin, s'il y a une copie de données à faire, que ce soit le système ou l'application qui s'en occupe ce sera aussi long

./3915 > Ouais bon, certes, je trouvais ça bizarre d'avoir les sockets dans la liste de handles qui pouvaient être hérités à la base (vu que pour moi c'était un composant séparé dans le système) mais je me suis laissé piéger par la documentation…
Après, ça reste quand même possible de transférer le socket entre un process et un autre avec WSADuplicateSocket… Et au moins c'est marqué dans la documentation (que tu viens de citer), même si de fait tu es *obligé* de lire la documentation pour le savoir. (Mais c'est assez normal en fait…)

GoldenCrystal (./3918) :
Pour le reste, est-ce tu penses que gérer toutes les erreurs (donc pas gérer "n'importe quelle erreur") y compris celles qui ne sont pas sensées arriver est vraiment une bonne pratique ? Personnellement je ne suis pas de cet avis. (Après, c'est le problème que j'ai avec les codes d'erreur en retour de méthode, c'est trop facile à ignorer à l'inverse des exceptions…)

Je dirais que ça dépends du type de programme : pour un jeu-vidéo, peut-être pas, mais si à une application où la notion de sécurité est importante, traiter les cas normalement impossibles, c'est la base.

s'il y a une copie de données à faire, que ce soit le système ou l'application qui s'en occupe ce sera aussi long

En théorie, oui. En pratique, il peut y avoir des différences significatives d'un OS à un autre, suivant la qualité de la gestion de la mémoire virtuelle et des I/O stockage de masse et réseau
Je me souviens, par exemple, que les I/O stockage de masse étaient, il y a quelques années, le domaine où un benchmark Windows tout à fait classique, tournant sous Wine sous Linux, était le plus rapide par rapport au même benchmark tournant sous Windows natif. Il y avait un facteur supérieur à 2 en faveur de Wine sur cet aspect (et un facteur > 4 dans l'autre sens sur certaines features DirectX 9). C'est une des manifestations du fait que les I/O stockage de masse sont traditionnellement mieux gérées sous Linux que sous Windows.
En HPC, seules des entités bizarres utilisent autre chose que Linux - et ce n'est pas seulement pour le coût des licences.

ici le soucis n'est pas le temps de la copie, c'est la duplication des 10GB de ram pour garantir l'atomicité de la save

alors soit tu duplique tout, soit tu te repose sur l'os avec fork, soit tu récré tout seul dans ton prog cette gestion de fork/partage de page de mémoire, soit tu va foutre le bordel dans ton appli (qui étais super simple à l'origine) pour gérer ce cas :- /

edit > cross

robinHood (./3913) :
je ne connais pas grand chose à la prog système avec de multiples process et thread mais je peut vous donner un exemple ou fork est indispensable, redis

cette base met tout en ram, elle peut prendre 10 giga sans soucis

pour assurer la persistance celle ci se dumpe intégralement (ou non, mais prenons le cas intégral ici) sur le disque

cette opération peu prendre du temps, mais le but de redis est d'être rapide, très rapide, donc la base doit être dispo (et pas en lecture seule) durant le dump

bref, elle doit avoir un shoot propre à dumper, qui ne va pas non plus se modifier durant ce dump, et on ne va pas dupliquer 10GB de ram, bref redis forke, le process forké fait son dump pendant que l'original lui continu à servir les clients et modifier si il le faut sa version

une explication ici http://redis.io/topics/faq

alors soit on laisse linux faire sa magie, le code de redis restant simple et efficace, soit on modifie redis en profondeur pour qu'il puisse à la fois dumper et servir en même temps, c'est ce qu'on fait des gars de chez microsoft

pourquoi ne pas faire un thread ?

ici l’intérêt est la gestion automatique par l'os via fork de deux instances différentes (ou non) des 10GB de ram, après que se soit un thread ou un clone du process qui fait la save en // on s'en tape

(bon je n'ai jamais moi même utilisé fork ou eu besoin d'avoir deux instances de gros packets de ram donc il existe peut être un moyen d'avoir ces instances sans faire le fork ? mais le principe d'avoir de manière automatique des pages de ram communes et des pages "forkés" est génial je trouve)

(accessoirement, dans sa philosophie actuelle redis est mono thread, si tu veut utiliser plusieurs coeur lance plusieurs instances du serveur, soit indépendantes soit en master/slave)

flanker (./3922) :
pourquoi ne pas faire un thread ?

Parce que le but est de travailler sur une version des données qui n'est plus modifiée ?

flan: dans ce cas c'est le copy-on-write qui sert. seules les pages mémoires modifiées par le fils sont allouées en deux exemplaires, les autres restent partagées.

flanker (./3917) :
Bin les logiciels en question n'ont qu'à respecter la norme POSIX

Manque de chance, fork est spécifié par POSIX: http://pubs.opengroup.org/onlinepubs/009695399/functions/fork.html (et d'ailleurs, la révision de 2001 rajoute la phrase "After fork(), both the parent and the child processes shall be capable of executing independently before either one terminates." qui interdit fork=vfork, qui était encore toléré en 1998).

Le problème, c'est la clause: "Consequently, to avoid errors, the child process may only execute async-signal-safe operations until such time as one of the exec functions is called." à laquelle Apple rajoute "All APIs, including global data symbols, in any framework or library should be assumed to be unsafe after a fork() unless explicitly documented to be safe or async-signal safe. If you need to use these frameworks in the child process, you must exec." En gros, seul ce pour quoi POSIX exige que ce soit async-signal-safe l'est, toutes les APIs que OS X propose en dehors POSIX ne sont pas async-signal-safe! C'est "génial" quand tu dois utiliser une de leurs APIs non-standard pour intégrer ton application correctement à leur "UNIX, mais pas tout à fait".

Ce qu'il y a bien avec toi, c'est que tu considères que le standard à respecter est ce qui est ni un standard officiel (ISO), ni un truc utilisé sur la majorité des machines, mais bien un truc qui utilisé sur 1% des machines...

Le problème ici est que leur interprétation du standard POSIX n'est pas raisonnable, ils n'implémentent que le strict minimum pour être certifiables UNIX, toutes les options prévues pour un système desktop ne marchent pas et l'interopérabilité entre les APIs POSIX et leurs APIs propriétaires est pourrie (comme dans le cas présent)!

Donc Apple respecte POSIX, tu devrais râler contre la norme si tu la trouves pourrie, pas contre Apple

Il y a presque toujours moyen d'implémenter un standard à la lettre tout en développant quelque chose de totalement inutilisable en pratique. Par exemple, IP over Avian Carrier est une implémentation conforme de TCP/IP.

Pour développer quelque chose d'utilisable, il faut se demander à quoi sert le standard, quelles options il faut implémenter pour répondre aux attentes des utilisateurs et pourquoi (et dans quel but) il y a certaines clauses. Si on veut juste avoir la certification et on se fiche du reste, on se demande à la place comment remplir le standard avec le minimum absolu d'effort, et c'est ce qu'Apple a fait. Résultat: Ça ne sert strictement à rien!

robinHood (./3921) :
ici le soucis n'est pas le temps de la copie, c'est la duplication des 10GB de ram pour garantir l'atomicité de la save

alors soit tu duplique tout, soit tu te repose sur l'os avec fork, soit tu récré tout seul dans ton prog cette gestion de fork/partage de page de mémoire, soit tu va foutre le bordel dans ton appli (qui étais super simple à l'origine) pour gérer ce cas :- /

edit > cross

Le coup du copy-on-write devrait être une fonction à associer au handle ("tiens copie-moi virtuellement ce bloc mémoire", et la copie serait réellement faite au moment de la première écriture), et pas quelque chose qui nécessite fork, car c'est conceptuellement une bidouille considérant l'objectif final. A mon avis là tu réfléchis trop en Linuxien.

donc on peut faire cette copie "virtuelle" sans devoir faire forcément un fork ? ca rulez

mais dans tous les cas la save doit être faite en // pour ne pas être bloquante donc fork() est tout désigné non ?

(en l’occurrence ce n'est pas une simple copie ram -> disque il y à de la compression etc, mais si cela n'avais pas été le cas, aurait' on pu demander au système de faire cette copie de manière asynchrone ?)

Linuxien

wow maintenant je vais devoir me faire pousser la barbe