Kevin > plus sérieusement, j'ai monté mon pc, il n'était donc vendu avec aucune licence. C'est assez facile de faire ce qu'on veut avec un fixe.
Pour les portables, c'est vrai que c'est ennuyeux de lier les deux, on est coincé.
Kevin Kofler (./3860) :
La définition dit "chantage, intimidation ou violence". Il n'y a pas intimidation ni violence, mais il y a bien chantage quand la majorité des ordinateurs ne sont pas vendus sans système d'exploitation. "Tu veux un ordinateur? Alors tu dois acheter notre système d'exploitation avec!"
Kevin Kofler (./3868) :
Ah, j'oubliais, vous êtes des moutons qui achètent tout ce que la majorité utilise, donc dans ce cas-là vous seriez tous là à nous raconter comment RHEL est bien et tout le reste est pourri…
Kevin Kofler (./3866) :
Tiens, justement, pour ceux qui défendent le racketiciel: Imaginez que presque toutes les machines soient vendues avec RHEL et qu'il soit presqu'impossible d'acheter une machine sans RHEL (et donc sans payer Red Hat) pour y mettre votre système d'exploitation bien aimé. Ne vous plaindriez-vous pas?
GoldenCrystal (./3869) :
(Et honnêtement d'un point de vue de développeur, je trouve les API de Windows infiniment mieux fichus que tout ce qu'on retrouve dans le monde Unix… Donc ça me ferait énormément chier sur ce plan.)
Yoshi Noir (./3872) :
Puis de la part de quelqu'un qui ne jure que par Fedora et qui envoie des doigts à quiconque n'utilise pas ta distribution chérie, laisse-moi rigoler sur ta pseudo-tolérance.
Donc ce serait une solution pour ceux qui veulent à tout prix quelque chose de préinstallé.
Kevin Kofler (./3873) :Wah, quel argument !GoldenCrystal (./3869) :
(Et honnêtement d'un point de vue de développeur, je trouve les API de Windows infiniment mieux fichus que tout ce qu'on retrouve dans le monde Unix… Donc ça me ferait énormément chier sur ce plan.)
lpczstrNon!
Je ne sais pas dans quel monde tu vis, mais si Fedora était préinstallé partout, t'inquiète pas que ce serait tout sauf grauit.Yoshi Noir (./3872) :
Puis de la part de quelqu'un qui ne jure que par Fedora et qui envoie des doigts à quiconque n'utilise pas ta distribution chérie, laisse-moi rigoler sur ta pseudo-tolérance.
Même si on préinstallait Fedora partout, ce ne serait pas un racketiciel parce que c'est gratuit.Donc ce serait une solution pour ceux qui veulent à tout prix quelque chose de préinstallé.
GoldenCrystal (./3878) :
À côté, CreateProcess, CreateThread, CreateWindow, je me demande ce que ça peut bien vouloir dire…
)GoldenCrystal (./3878) :
(Sinon j'aime bien comment tu esquives à chaque fois la moitié du post qui est gênante pour toi… Tu ne penses pas que piquer l'argent du contribuable pour te payer à glander dans une université toute ta vie c'est du racket ? Tu crois vraiment que distribuer Red Hat sur tous les PC vendus serait vraiment gratuit ?)
GoldenCrystal (./3878) :
À côté, CreateProcess, CreateThread, CreateWindow, je me demande ce que ça peut bien vouloir dire…
Kevin Kofler (./3883) :Ouais et je vois pas à quoi ça sert… À part faire des économies de bouts de chandelle sur la création d'un truc super coûteux au système et qui ne devrait se produire qu'occasionnellement…
Et si tu veux créer un nouveau processus sans lancer un nouvel exécutable, tu l'as fort dans le c…
avec ta "magnifique" API parce qu'il n'y a même pas une fonction aussi élémentaire que fork()!Fork est typiquement un truc que je ne peux pas saquer dans la philosophie Unix.
pour le fork() (c'est marrant, j'en causais justement avec Folco il y a quelques jours)
GoldenCrystal (./3884) :
On a pas besoin de foker parce qu'on a un truc mieux (plus léger, plus performant, plus pratique) que les processus pour faire du multi-tâches : les threads. (Ça existait (correctement) sous Windows avant Linux hein…)
Et sinon, tu ne penses pas que piquer l'argent du contribuable pour te payer à glander dans une université toute ta vie c'est du racket ?
Et est-ce que tu crois vraiment que distribuer Red Hat sur tous les PC vendus serait vraiment gratuit ?
Kevin Kofler (./3887) :Quelle sécurité ?GoldenCrystal (./3884) :Plus performant, certes, mais offrant moins d'isolation, donc moins fiable et pire au niveau de la sécurité.
On a pas besoin de foker parce qu'on a un truc mieux (plus léger, plus performant, plus pratique) que les processus pour faire du multi-tâches : les threads. (Ça existait (correctement) sous Windows avant Linux hein…)
Ben vu que tu es contre le fait d'être rémunéré pour ton travail, y'a peu de chances que tu ailles bosser en entreprise…Et sinon, tu ne penses pas que piquer l'argent du contribuable pour te payer à glander dans une université toute ta vie c'est du racket ?Dèjà, qui te dit que je vais passer toute ma vie à l'université?
Franchement, tes attaques personnelles sont tellement sottes qu'elles ne mériteraient même pas de réponse, mais comme tu n'arrêtes pas de répéter ces conneries, j'étais bien obligé d'y répondre.Ben justement, tu n'as pas répondu à ma question…
OK alors permet moi de modifier ma question : Et est-ce que tu crois vraiment que distribuer Fedora™©® sur tous les PC vendus serait vraiment gratuit ?Et est-ce que tu crois vraiment que distribuer Red Hat sur tous les PC vendus serait vraiment gratuit ?RHEL non, Fedora oui.
Ou sinon, il y aurait vite une autre distribution gratuite que les OEMs choisiraient à la placeOK alors permet moi de modifier ma question : Et est-ce que tu crois vraiment que distribuer N'importe quel système d'exploitation gratuit basé sur GNU/Linux, approuvé par la FSF et béni par Saint RMS™ sur tous les PC vendus serait vraiment gratuit ?
si leur but était de vendre leur matériel le moins cher possible comme il devrait l'être.Ça tombe bien, c'est justement le cas…
)
GoldenCrystal (./3888) :Euh là j'ai très peur par contre. C'est de la provoc ou tu le penses vraiment ?
Le code c'est toi qui l'a écrit, y'a aucune faille de sécurité si tu as codé proprement
spectras (./3889) :Je n'ai jamais dit le contraire. Ma remarque se porte sur fork, pas sur l'utilité des processus vs threads.
./3884> tu déconnes quand même, les threads et les processus sont des outils bien distincts, et l'un ne remplacera juste jamais l'autre.
=> deux threads avec des droits différents ?Je ne suis pas sûr de comprendre la question. (Différence avec celle d'en dessous ?)
=> deux threads avec une identité différente ?Je ne m'en suis jamais servi, mais je sais que c'est possible : http://msdn.microsoft.com/en-us/library/windows/desktop/aa376391(v=vs.85).aspx
=> deux threads avec une affinité mémoire différente pour les architectures numa (possible mais limité et moins efficace) ? (*)Ouais éventuellement, ça peut être chiant, mais démarrer ton processus une seule fois sur chaque groupe de CPU suffit largement et je ne vois pas où ça serait beaucoup plus compliqué…
Et il y a également des usages de fork qui ne sont pas remplaçables par des threads. Quid du pre-linking en mémoire par exemple ?Je ne suis pas certain de bien comprendre l'intérêt, ou de bien comprendre tout court…
Toujours au sujet de la mémoire, parfois on peut avoir envie de libérer celle qui n'est plus utilisée, ce qui est rarement possible quand tes threads partagent le même heap (= tout le temps ?). Les threads se créent et meurent, mais la fragmentation du heap persiste, souci que tu n'as pas avec des process.Certes, mais Windows te permet aussi d'utiliser plusieurs heaps, par exemple… (Pas avec la libc bien sûr)
(*) d'ailleurs question jocker : comment tu changes l'affinité d'un thread dans la super api windows ?Merci d'y répondre toi-même, sinon je t'aurais gentiment pointé vers la page MSDNOui, oui la fonction existe, mais comment tu lui fournis ses paramètres ?
J'ignore si ça a été corrigé depuis, mais il y a 2/3 ans le seul moyen était de faire un vieux dllimport de kernel32.dll et d'y chercher le point d'entrée de GetCurrentThread(), comme à l'époque de grand-papa, c'était classe en plein code managé.Ah en .NET par contre… ^^ C'est un peu la merde effectivement.
Les deux. Je m'exprime peut-être mal, mais :GoldenCrystal (./3888) :Euh là j'ai très peur par contre. C'est de la provoc ou tu le penses vraiment ?
Le code c'est toi qui l'a écrit, y'a aucune faille de sécurité si tu as codé proprement
GoldenCrystal (./3888) :
Quelle sécurité ?
De plus y'a au moins autant de failles dans un processus forké, puisque celui-ci contient toutes les informations du processus parent au moment du fork (sauf celles modifiées) ainsi que tout le code parent, et possède le moyen de communiquer avec son parent pour lui faire faire tout ce qui est permis par le protocole IPC utilisé, y compris l'exploitation des bugs de celui-ci…
Tu te plains qu'on te fasse payer un logiciel qui te permet d'utiliser ton pc à la sortie de la boite (de payer le travail de ceux qui ont conçu ce logiciel !) et qui sera vraisemblablement utilisé par au moins 99% des gens qui achèteront la boîte.
Donc moi, j'aimerais savoir si, pour un contribuable qui est forcé de payer ses impôts (et qui paye ses impôts en bon citoyen), payer quelqu'un comme toi qui ne lui apporte absolument rien du tout, c'est pas du racket. (Quel service tu rends à ce citoyen concrètement ?)
OK alors permet moi de modifier ma question : Et est-ce que tu crois vraiment que distribuer N'importe quel système d'exploitation gratuit basé sur GNU/Linux, approuvé par la FSF et béni par Saint RMS™
sur tous les PC vendus serait vraiment gratuit ?
si leur but était de vendre leur matériel le moins cher possible comme il devrait l'être.Ça tombe bien, c'est justement le cas…
Et tu soulèves un point important : Leur but est de vendre
le matériel.
GoldenCrystal (./3891) :Et il y a également des usages de fork qui ne sont pas remplaçables par des threads. Quid du pre-linking en mémoire par exemple ?Je ne suis pas certain de bien comprendre l'intérêt, ou de bien comprendre tout court…
Ah en .NET par contre… ^^ C'est un peu la merde effectivement.
D'une part, si tu as bien codé, il n'y a aucune faille dans ton code
Zerosquare (./3892) :
Celle-là va faire s'étouffer Kevin
- Fedora est constitué des anciennes versions de Red Hat, tombées en abandonware.
Kevin Kofler (./3893) :Ouais, j'ai déjà entendu dire que Apache était bogué et plein de fuites mémoire, ce qui l'aurait empêché de fonctionner de manière multithread. J'ai aucune idée de la véracité de ce propos, mais si c'est vrai tout ce que ça tend à prouver c'est que fork == cache misère pour un code de merde.
Par exemple, Apache forke pour isoler les requêtes les unes des autres.
Mais tu n'as pas accès aux autres processus fils.La même faille est dispo dans tous les autres processus fils, ça peut très bien être suffisant pour pourrir ta machine et te faire perdre de l'argent…
"Au moins 99% des gens"? La part de marché de GNU/Linux dépasse 1%.Avant d'annoncer ça, j'aimerais savoir comment sont calculés ces 1%… Par exemple, moi, je compte pour Windows ou pour OSX ? Ou pour les deux ? À combien de % chacun ?
)Et puis personnellement, j'ai acheté une machine sans système d'exploitation, j'ai probablement payé plus cher au final, mais je n'ai pas payé pour quelque chose que je ne veux pas.Sur le principe de ne pas payer ce que tu ne veux pas je te suis, mais payer plus cher pour ne pas payer ce que tu ne veux pas, c'est juste
De plus, j'ai aussi pu configurer pas mal de détails au niveau du matériel et j'ai donné mon argent à une entreprise locale qui donne le choix d'acheter son matériel sans système d'exploitation (c'est toujours le cas, maintenant même les modèles préconfigurés sont vendus sans système d'exploitation) plutôt qu'à une multinationale qui soutient le racket. Malheureusement, la vente liée est toujours la norme.Ouais en gros t'as juste payé plus cher comme l'aurait fait un papy qui n'a aucune connaissance en informatique. (Et ces petites boutiques n'ont probablement pas de contrat avec les éditeurs de logiciel ou les fabriquant de matériel qui leur permettraient de baisser les coûts de l'ensemble, donc au final t'es pas vraiment gagnant
)Je fais de la recherche. Sans recherche, on serait toujours à l'âge de la pierre. Jette ton PC par la fenêtre et va jouer avec ton silex.Ça ne répond pas à la question, et en plus c'est faux : L'idée de la recherche en tant que métier c'est un truc relativement récent. On a pas attendu d'avoir des chercheurs pour découvrir le feu et découvrir comment forger.
Installation automatisée (kickstart), on insère le DVD (ou le câble réseau pour utiliser le PXE) et on reboote la machine, quelques secondes de plus pendant l'assemblage de la machine, négligeables…Oui mais tu ne traites que 1-10% du problème, il te manque tout le reste.
Ce n'est pas là que part l'argent du racketiciel!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 ?
Bah non, sinon ils ne t'obligeraient pas à acheter un système d'exploitation payant qui gonfle le prix de leur matériel alors que ce n'est pas du tout nécessaire.
Le matériel, pas le logiciel qui n'est même pas d'eux.Excuse moi, j'avais oublié qu'en tant qu'intégriste FSF, tu n'étais pas très familier avec la notion de valeur ajoutée.
Kevin Kofler (./3894) :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…
L'intérêt, c'est la performance, et si tu ne comprends pas le principe, documente-toi sur le "kdeinit hack". (En gros, au lieu de fork+exec, kdeinit fait fork+dlopen et on peut donc profiter des DLLs (enfin, .so) préchargées par kdeinit.)
D'une part, si tu as bien codé, il n'y a aucune faille dans ton code
GoldenCrystal (./3896) :
Ben si, t'as qu'à regarder le code d'un hello world quelconque, une grande partie sont exempts de bugs.
Puis ça dépendra aussi du compilateur et du linker, l'absence de faille 
GoldenCrystal (./3896) :Je suis prêt à parier que seule une très petite minorité fait sa gestion d'erreurs correctement.
Ben si, t'as qu'à regarder le code d'un hello world quelconque, une grande partie sont exempts de bugs.
spectras (./3898) :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.
je pensais notamment aux cas de serveurs, où les besoins de changement d'identité / de permissions ont lieu après initiation de la connexion (voire après la négociation SSL, le cas échéant). Initialiser un nouveau processus et lui transférer la requète via IPC (puis récupérer la réponse afin de la transmettre au client) serait une contre-performance notoire.
spectras (./3898) :Je serais curieux de savoir combien de temps la résolution des références prend sur une machine moderne. Je me trompe peut-être, mais je doute que ce soit significatif.
Pour le pre-linking en mémoire, l'idée est d'avoir un processus qui charge un ensemble de libs, ce qui les linke. Il peut alors lancer des programmes qui utilisent ces libs très rapidement, il n'a qu'à forker et les libs sont déjà prêtes, avec toutes les références résolues. Ça présente aussi l'avantage de permettre de réduire la mémoire consommée par chaque processus, car les structures dynamiques communes sont partagées sur des pages en copy-on-write. Je sais que kdeinit fait ça, il n'est sans doute pas le seul.
