Dis moi mon grand, tu n'aurais pas un peu trop picolé... Vas te reposer un peu çà te fera du bien.
Quand on ne sait pas de quoi qu'on cause, on cause pas... C'est mieux pour tout le monde, parce que là tu m'as mis de mauvaise humeur pour les DIx minutes qui suivents. Je te rassure au dela des dix minutes, je vais pouffer de rire en moquant des abrutis qui pense encore que windows est un système d'exploitation, alors qu'il n'est qu'un vague gadget inutile.
A titre d'info, Ô grand gourou de la naiserie, le fameux Mac OS X que tu cites fonctionne grâce à un noyau linux...
Mdr,
Super le troll !
On m'avais habitué à mieux.
Dis moi mon grand, tu n'aurais pas un peu trop picolé...
Vas te reposer un peu çà te fera du bien.
Quand on ne sait pas de quoi qu'on cause, on cause pas...
C'est mieux pour tout le monde, parce que là tu m'as mis de mauvaise
humeur pour les DIx minutes qui suivents. Je te rassure au dela des dix
minutes, je vais pouffer de rire en moquant des abrutis qui pense
encore que windows est un système d'exploitation, alors qu'il n'est
qu'un vague gadget inutile.
A titre d'info, Ô grand gourou de la naiserie, le fameux Mac OS X que
tu cites fonctionne grâce à un noyau linux...
Dis moi mon grand, tu n'aurais pas un peu trop picolé... Vas te reposer un peu çà te fera du bien.
Quand on ne sait pas de quoi qu'on cause, on cause pas... C'est mieux pour tout le monde, parce que là tu m'as mis de mauvaise humeur pour les DIx minutes qui suivents. Je te rassure au dela des dix minutes, je vais pouffer de rire en moquant des abrutis qui pense encore que windows est un système d'exploitation, alors qu'il n'est qu'un vague gadget inutile.
A titre d'info, Ô grand gourou de la naiserie, le fameux Mac OS X que tu cites fonctionne grâce à un noyau linux...
Fred
Le Wed, 17 May 2006 18:50:45 +0000, Michel Talon a écrit :
En ce qui me concerne j'ai tourné sous Debian Woody pendant une année complète pour dire que j'étais persévérant, et je n'ai jamais autant compilé de programmes de ma vie. Et obligé de fabriquer l'infrastructure Debian à coups de dh-make et de vi pour fabriquer des .deb que je puisse désinstaller.
Ça me rappelle l'époque où je tournais sous Mandrake, j'ai découvert l'option -ta de rpm qui permet de fabriquer un paquet binaire rpm à partir du tarball (même pas besoin de décompresser), à partir du moment où il a été prévu pour ça (ce qui était très souvent le cas).
Je trouve que c'est exactement le genre d'option qui manque à dpkg, ce qui est vraiment dommage car beaucoup de tarball viennent avec un répertoire debian.
--
Your supervisor is thinking about you.
Le Wed, 17 May 2006 18:50:45 +0000, Michel Talon a écrit :
En ce qui me concerne j'ai tourné sous Debian Woody pendant une année complète
pour dire que j'étais persévérant, et je n'ai jamais autant compilé de
programmes de ma vie. Et obligé de fabriquer l'infrastructure Debian à coups
de dh-make et de vi pour fabriquer des .deb que je puisse désinstaller.
Ça me rappelle l'époque où je tournais sous Mandrake, j'ai découvert
l'option -ta de rpm qui permet de fabriquer un paquet binaire rpm à
partir du tarball (même pas besoin de décompresser), à partir du moment
où il a été prévu pour ça (ce qui était très souvent le cas).
Je trouve que c'est exactement le genre d'option qui manque à dpkg, ce
qui est vraiment dommage car beaucoup de tarball viennent avec un
répertoire debian.
Le Wed, 17 May 2006 18:50:45 +0000, Michel Talon a écrit :
En ce qui me concerne j'ai tourné sous Debian Woody pendant une année complète pour dire que j'étais persévérant, et je n'ai jamais autant compilé de programmes de ma vie. Et obligé de fabriquer l'infrastructure Debian à coups de dh-make et de vi pour fabriquer des .deb que je puisse désinstaller.
Ça me rappelle l'époque où je tournais sous Mandrake, j'ai découvert l'option -ta de rpm qui permet de fabriquer un paquet binaire rpm à partir du tarball (même pas besoin de décompresser), à partir du moment où il a été prévu pour ça (ce qui était très souvent le cas).
Je trouve que c'est exactement le genre d'option qui manque à dpkg, ce qui est vraiment dommage car beaucoup de tarball viennent avec un répertoire debian.
--
Your supervisor is thinking about you.
Mihamina Rakotomandimby
On Wed, 17 May 2006 13:15:53 -0700, Jonas wrote:
Quand on ne sait pas de quoi qu'on cause, on cause pas... [...]
A titre d'info, Ô grand gourou de la naiserie, le fameux Mac OS X que tu cites fonctionne grâce à un noyau linux...
Oups....
On Wed, 17 May 2006 13:15:53 -0700, Jonas wrote:
Quand on ne sait pas de quoi qu'on cause, on cause pas...
[...]
A titre d'info, Ô grand gourou de la naiserie, le fameux Mac OS X
que tu cites fonctionne grâce à un noyau linux...
Quand on ne sait pas de quoi qu'on cause, on cause pas... [...]
A titre d'info, Ô grand gourou de la naiserie, le fameux Mac OS X que tu cites fonctionne grâce à un noyau linux...
Oups....
moinsdespam
Dans ,
A titre d'info, Ô grand gourou de la naiserie, le fameux Mac OS X que tu cites fonctionne grâce à un noyau linux...
Mouarfffff, je me marre comme une baleine.
-- Frédéric Bleu,e adj. et n. m. Qui est d'une couleur voisine du rouge, mais pas très : un ciel bleu, des yeux bleus, les flots bleus [..]. Fig. Bouch. : un steak bleu ; s'emploie pour désigner un steak rouge. (Pierre Desproges : D.S.U.É (et des BN))
Dans <1147896953.298088.167130@i39g2000cwa.googlegroups.com>,
A titre d'info, Ô grand gourou de la naiserie, le fameux Mac OS X que
tu cites fonctionne grâce à un noyau linux...
Mouarfffff, je me marre comme une baleine.
--
Frédéric
Bleu,e adj. et n. m. Qui est d'une couleur voisine du rouge, mais pas très : un
ciel bleu, des yeux bleus, les flots bleus [..]. Fig. Bouch. : un steak bleu ;
s'emploie pour désigner un steak rouge. (Pierre Desproges : D.S.U.É (et des BN))
A titre d'info, Ô grand gourou de la naiserie, le fameux Mac OS X que tu cites fonctionne grâce à un noyau linux...
Mouarfffff, je me marre comme une baleine.
-- Frédéric Bleu,e adj. et n. m. Qui est d'une couleur voisine du rouge, mais pas très : un ciel bleu, des yeux bleus, les flots bleus [..]. Fig. Bouch. : un steak bleu ; s'emploie pour désigner un steak rouge. (Pierre Desproges : D.S.U.É (et des BN))
Emmanuel Florac
Le Thu, 18 May 2006 08:20:06 +0200, Patrick Lamaizière a écrit :
Tout à fait. Mais justement, si Mac OS X fait mieux qu'une distrib Linux avec le même noyau y'a quand même des questions à se poser.
Mac OS X n'a pas le moindre rapport avec Linux. Le noyau de Mac OS X est basé sur MACH, avec par dessus une couche BSD qui vient essentiellement de FreeBSD. Par ailleurs, la performance du noyau de Mac OS X est épouvantable. Un Mac sous Linux est souvent 2 fois plus rapide que sous OS X, en particulier pour les applications serveurs (serveur de fichier, de base de données...). Par contre il est indéniable qu'Apple pourrait parfaitement décider de basculer son système sur un noyau Linux. Mais la licence les en empèche, n'oublions pas que Mac OS X est essentiellement un OS propriétaire avec des bouts libres dedans (le userland BSD, gcc...).
-- Mais monsieur, voudriez-vous que je me l'écorchasse? Barbey d'Aurevilly.
Le Thu, 18 May 2006 08:20:06 +0200, Patrick Lamaizière a écrit :
Tout à fait. Mais justement, si Mac OS X fait mieux qu'une distrib Linux
avec le même noyau y'a quand même des questions à se poser.
Mac OS X n'a pas le moindre rapport avec Linux. Le noyau de Mac OS X est
basé sur MACH, avec par dessus une couche BSD qui vient essentiellement
de FreeBSD.
Par ailleurs, la performance du noyau de Mac OS X est épouvantable. Un
Mac sous Linux est souvent 2 fois plus rapide que sous OS X, en
particulier pour les applications serveurs (serveur de fichier, de base de
données...).
Par contre il est indéniable qu'Apple pourrait parfaitement décider de
basculer son système sur un noyau Linux. Mais la licence les en empèche,
n'oublions pas que Mac OS X est essentiellement un OS propriétaire avec
des bouts libres dedans (le userland BSD, gcc...).
--
Mais monsieur, voudriez-vous que je me l'écorchasse?
Barbey d'Aurevilly.
Le Thu, 18 May 2006 08:20:06 +0200, Patrick Lamaizière a écrit :
Tout à fait. Mais justement, si Mac OS X fait mieux qu'une distrib Linux avec le même noyau y'a quand même des questions à se poser.
Mac OS X n'a pas le moindre rapport avec Linux. Le noyau de Mac OS X est basé sur MACH, avec par dessus une couche BSD qui vient essentiellement de FreeBSD. Par ailleurs, la performance du noyau de Mac OS X est épouvantable. Un Mac sous Linux est souvent 2 fois plus rapide que sous OS X, en particulier pour les applications serveurs (serveur de fichier, de base de données...). Par contre il est indéniable qu'Apple pourrait parfaitement décider de basculer son système sur un noyau Linux. Mais la licence les en empèche, n'oublions pas que Mac OS X est essentiellement un OS propriétaire avec des bouts libres dedans (le userland BSD, gcc...).
-- Mais monsieur, voudriez-vous que je me l'écorchasse? Barbey d'Aurevilly.
Khanh-Dang
(Michel Talon) wrote:
Non je suis désolé, l'utilitaire de Windows, "ajout suppression de programmes" est infiniment plus simple à utiliser que n'importe quel système de paquets Linux ou *BSD, parcequ'il permet d'ajouter et de retirer des programmes indépendamment les uns des autres et sans foutre la merde. Cette simple exigence n'est satisfaite par aucun système de paquets Linux *BSD. Dans tous les cas on est sûr de se mettre dans la panade si on veut upgrader un programme de façon aventureuse.
Il ne faudrait pas non plus confondre la simplicité des utilitaires avec la simplicité du rôle qu'on leur demande de remplir.
On est bon pour une compilation à partir des sources et encore si on a de la chance avec les autoconf, automake, etc.
Disons dans un élan de simplification à outrance que c'est le caractère open source de tes programmes qui amènent à la pluralité des distributions et qui font que les développeurs ont la flemme légitime de faire des paquets pour chacune des distributions existantes.
Ton système de paquets ça marche uniquement quand tu acceptes les paquets qui sont fournis par ta distribution, ce qui est rarement le cas pour moi.
Mauvaise distribution, changer de distribution. Ou alors, demander aux personnes s'occupant de faire des paquets d'en faire un pour ton programme. Ou bien de demander à une connaissance de le faire. Ou bien le faire toi-même.
talon@lpthe.jussieu.fr (Michel Talon) wrote:
Non je suis désolé, l'utilitaire de Windows, "ajout suppression de programmes"
est infiniment plus simple à utiliser que n'importe quel système de paquets
Linux ou *BSD, parcequ'il permet d'ajouter et de retirer des programmes
indépendamment les uns des autres et sans foutre la merde. Cette simple
exigence n'est satisfaite par aucun système de paquets Linux *BSD. Dans tous
les cas on est sûr de se mettre dans la panade si on veut upgrader un
programme de façon aventureuse.
Il ne faudrait pas non plus confondre la simplicité des utilitaires
avec la simplicité du rôle qu'on leur demande de remplir.
On est bon pour une compilation à partir des
sources et encore si on a de la chance avec les autoconf, automake, etc.
Disons dans un élan de simplification à outrance que c'est le caractère
open source de tes programmes qui amènent à la pluralité des
distributions et qui font que les développeurs ont la flemme légitime
de faire des paquets pour chacune des distributions existantes.
Ton système de paquets ça marche uniquement quand tu acceptes les paquets qui
sont fournis par ta distribution, ce qui est rarement le cas pour moi.
Mauvaise distribution, changer de distribution. Ou alors, demander aux
personnes s'occupant de faire des paquets d'en faire un pour ton
programme. Ou bien de demander à une connaissance de le faire. Ou bien
le faire toi-même.
Non je suis désolé, l'utilitaire de Windows, "ajout suppression de programmes" est infiniment plus simple à utiliser que n'importe quel système de paquets Linux ou *BSD, parcequ'il permet d'ajouter et de retirer des programmes indépendamment les uns des autres et sans foutre la merde. Cette simple exigence n'est satisfaite par aucun système de paquets Linux *BSD. Dans tous les cas on est sûr de se mettre dans la panade si on veut upgrader un programme de façon aventureuse.
Il ne faudrait pas non plus confondre la simplicité des utilitaires avec la simplicité du rôle qu'on leur demande de remplir.
On est bon pour une compilation à partir des sources et encore si on a de la chance avec les autoconf, automake, etc.
Disons dans un élan de simplification à outrance que c'est le caractère open source de tes programmes qui amènent à la pluralité des distributions et qui font que les développeurs ont la flemme légitime de faire des paquets pour chacune des distributions existantes.
Ton système de paquets ça marche uniquement quand tu acceptes les paquets qui sont fournis par ta distribution, ce qui est rarement le cas pour moi.
Mauvaise distribution, changer de distribution. Ou alors, demander aux personnes s'occupant de faire des paquets d'en faire un pour ton programme. Ou bien de demander à une connaissance de le faire. Ou bien le faire toi-même.
Manuel Leclerc
Je te rassure au dela des dix minutes, je vais pouffer de rire en moquant des abrutis qui pense encore que windows est un système d'exploitation, alors qu'il n'est qu'un vague gadget inutile.
A titre d'info, Ô grand gourou de la naiserie, le fameux Mac OS X que tu cites fonctionne grâce à un noyau linux...
Les bras m'en tombent.
-- If it isn't backward compatible, people won't use it. X may suck, but it doesn't suck hard enough that people will abandon all their currently mostly-working software. --Valdis Kletnieks
Je te rassure au dela des dix minutes, je vais
pouffer de rire en moquant des abrutis qui pense
encore que windows est un système d'exploitation,
alors qu'il n'est qu'un vague gadget inutile.
A titre d'info, Ô grand gourou de la naiserie, le
fameux Mac OS X que tu cites fonctionne grâce à un
noyau linux...
Les bras m'en tombent.
--
If it isn't backward compatible, people won't use it. X may suck,
but it doesn't suck hard enough that people will abandon all their
currently mostly-working software. --Valdis Kletnieks
Je te rassure au dela des dix minutes, je vais pouffer de rire en moquant des abrutis qui pense encore que windows est un système d'exploitation, alors qu'il n'est qu'un vague gadget inutile.
A titre d'info, Ô grand gourou de la naiserie, le fameux Mac OS X que tu cites fonctionne grâce à un noyau linux...
Les bras m'en tombent.
-- If it isn't backward compatible, people won't use it. X may suck, but it doesn't suck hard enough that people will abandon all their currently mostly-working software. --Valdis Kletnieks
sansflotusspam
Michel Talon wrote:
sansflotusspam wrote:
Avec Window$, le programme "supergenius-3.2" exige la "supermachine.dll" (j'ai pas dit bwcc.dll ... ça rappellerait des souvenirs) ; l'installeur_qui_fait_tout_seul (installshield au hasard) dit : ya pas la supermachine.dll ! On regarde dans c:windows, et YA la supermachine.dll ! Oui, mais pas la version attendue par supergenius-3.2 En théorie, on peut mettre la DLL dans la même directory que le programme
et ça marche comme ça.
ça PEUT marcher comme ça, mais ça dépend énormément du programme et du programmeur ; les programmeurs window$ utilisent le plus souvent des "générateurs" ou pseudo-générateurs (visual-machin, windev, etc) qui ont la triste manie de mettre les appels systèmes "en dur" dans l'exe. conséquence : quand l'exe appelle une machin.dll, c'est obligatoirement c windowsmachin.dll, la c:tototatamachin.dll ne sera jamais cherchée ni trouvée. j'affronte régulièrement ce cas de figure chez mes clients avec des applis "métier", on devrait dire "progiciel spécialisé" ; la seule solution viable est de spécialiser le poste avec uniquement cette appli dessus. j'appelle ça "mal foutu".
Les paquets pour Windows bien foutus viennent avec toutes leurs dépendances originales dans leur propre directory et, pour moi, ça marche. Je n'ai jamais eu le moindre problème à mettre et enlever des programmes sous Windows, et j'ai gardé les mêmes de Win98 à WinXP.
vous avez tout dit : "bien foutus" ! il n'y en a pas beaucoup ... moi aussi, j'utilise 2 applis window$, indispensables et qui n'existent "nulle part ailleurs", datant de Win95, et que je fais tourner dans un Win98SE sous Qemu.
je vous accorde qu'il existe des poissons volants, reconnaissons ensemble que ce n'est pas la généralité du genre ...
Cher Michel, vous poussez le bouchon un tantinet trop loin ! OK, urpmi, apt-get, synaptic, yast, portage et consorts ne sont pas parfaits, mais ça fonctionne très bien dans 95% des cas. Évidemment, si on veut à tout prix installer un paquet compilé pour une Mandriva 2006 dans une Süse 5, il y a des chances que ça ne passe pas.
En ce qui me concerne j'ai tourné sous Debian Woody pendant une année complète pour dire que j'étais persévérant, et je n'ai jamais autant compilé de programmes de ma vie. Et obligé de fabriquer l'infrastructure Debian à coups de dh-make et de vi pour fabriquer des .deb que je puisse désinstaller.
normal, Debian est comme ça, bravo pour l'audace ! je me suis contenté d'ambitions plus modestes, Mandrake et Süse pour les postes "de boulot", plein d'exotiques pour le "loisir", et ça roule.
Avec Window$, le programme "supergenius-3.2" exige la
"supermachine.dll" (j'ai pas dit bwcc.dll ... ça rappellerait des
souvenirs) ; l'installeur_qui_fait_tout_seul (installshield au hasard)
dit : ya pas la supermachine.dll ! On regarde dans c:windows, et YA la
supermachine.dll ! Oui, mais pas la version attendue par supergenius-3.2
En théorie, on peut mettre la DLL dans la même directory que le programme
et ça marche comme ça.
ça PEUT marcher comme ça, mais ça dépend énormément du programme et du
programmeur ; les programmeurs window$ utilisent le plus souvent des
"générateurs" ou pseudo-générateurs (visual-machin, windev, etc) qui ont la
triste manie de mettre les appels systèmes "en dur" dans l'exe.
conséquence : quand l'exe appelle une machin.dll, c'est obligatoirement c
windowsmachin.dll, la c:tototatamachin.dll ne sera jamais cherchée ni
trouvée.
j'affronte régulièrement ce cas de figure chez mes clients avec des applis
"métier", on devrait dire "progiciel spécialisé" ; la seule solution viable
est de spécialiser le poste avec uniquement cette appli dessus.
j'appelle ça "mal foutu".
Les paquets pour Windows bien foutus viennent avec
toutes leurs dépendances originales dans leur propre directory et, pour
moi, ça marche. Je n'ai jamais eu le moindre problème à mettre et enlever
des programmes sous Windows, et j'ai gardé les mêmes de Win98 à WinXP.
vous avez tout dit : "bien foutus" ! il n'y en a pas beaucoup ...
moi aussi, j'utilise 2 applis window$, indispensables et qui n'existent
"nulle part ailleurs", datant de Win95, et que je fais tourner dans un
Win98SE sous Qemu.
je vous accorde qu'il existe des poissons volants, reconnaissons ensemble
que ce n'est pas la généralité du genre ...
Cher Michel, vous poussez le bouchon un tantinet trop loin !
OK, urpmi, apt-get, synaptic, yast, portage et consorts ne sont pas
parfaits, mais ça fonctionne très bien dans 95% des cas.
Évidemment, si on veut à tout prix installer un paquet compilé pour une
Mandriva 2006 dans une Süse 5, il y a des chances que ça ne passe pas.
En ce qui me concerne j'ai tourné sous Debian Woody pendant une année
complète pour dire que j'étais persévérant, et je n'ai jamais autant
compilé de programmes de ma vie. Et obligé de fabriquer l'infrastructure
Debian à coups de dh-make et de vi pour fabriquer des .deb que je puisse
désinstaller.
normal, Debian est comme ça, bravo pour l'audace !
je me suis contenté d'ambitions plus modestes, Mandrake et Süse pour les
postes "de boulot", plein d'exotiques pour le "loisir", et ça roule.
Avec Window$, le programme "supergenius-3.2" exige la "supermachine.dll" (j'ai pas dit bwcc.dll ... ça rappellerait des souvenirs) ; l'installeur_qui_fait_tout_seul (installshield au hasard) dit : ya pas la supermachine.dll ! On regarde dans c:windows, et YA la supermachine.dll ! Oui, mais pas la version attendue par supergenius-3.2 En théorie, on peut mettre la DLL dans la même directory que le programme
et ça marche comme ça.
ça PEUT marcher comme ça, mais ça dépend énormément du programme et du programmeur ; les programmeurs window$ utilisent le plus souvent des "générateurs" ou pseudo-générateurs (visual-machin, windev, etc) qui ont la triste manie de mettre les appels systèmes "en dur" dans l'exe. conséquence : quand l'exe appelle une machin.dll, c'est obligatoirement c windowsmachin.dll, la c:tototatamachin.dll ne sera jamais cherchée ni trouvée. j'affronte régulièrement ce cas de figure chez mes clients avec des applis "métier", on devrait dire "progiciel spécialisé" ; la seule solution viable est de spécialiser le poste avec uniquement cette appli dessus. j'appelle ça "mal foutu".
Les paquets pour Windows bien foutus viennent avec toutes leurs dépendances originales dans leur propre directory et, pour moi, ça marche. Je n'ai jamais eu le moindre problème à mettre et enlever des programmes sous Windows, et j'ai gardé les mêmes de Win98 à WinXP.
vous avez tout dit : "bien foutus" ! il n'y en a pas beaucoup ... moi aussi, j'utilise 2 applis window$, indispensables et qui n'existent "nulle part ailleurs", datant de Win95, et que je fais tourner dans un Win98SE sous Qemu.
je vous accorde qu'il existe des poissons volants, reconnaissons ensemble que ce n'est pas la généralité du genre ...
Cher Michel, vous poussez le bouchon un tantinet trop loin ! OK, urpmi, apt-get, synaptic, yast, portage et consorts ne sont pas parfaits, mais ça fonctionne très bien dans 95% des cas. Évidemment, si on veut à tout prix installer un paquet compilé pour une Mandriva 2006 dans une Süse 5, il y a des chances que ça ne passe pas.
En ce qui me concerne j'ai tourné sous Debian Woody pendant une année complète pour dire que j'étais persévérant, et je n'ai jamais autant compilé de programmes de ma vie. Et obligé de fabriquer l'infrastructure Debian à coups de dh-make et de vi pour fabriquer des .deb que je puisse désinstaller.
normal, Debian est comme ça, bravo pour l'audace ! je me suis contenté d'ambitions plus modestes, Mandrake et Süse pour les postes "de boulot", plein d'exotiques pour le "loisir", et ça roule.
Stéphane Zuckerman
On Wed, 17 May 2006, Jonas wrote:
Mdr,
Super le troll ! On m'avais habitué à mieux.
Dis moi mon grand, tu n'aurais pas un peu trop picolé... Vas te reposer un peu çà te fera du bien.
Quand on ne sait pas de quoi qu'on cause, on cause pas... C'est mieux pour tout le monde, parce que là tu m'as mis de mauvaise humeur pour les DIx minutes qui suivents. Je te rassure au dela des dix minutes, je vais pouffer de rire en moquant des abrutis qui pense encore que windows est un système d'exploitation, alors qu'il n'est qu'un vague gadget inutile.
A titre d'info, Ô grand gourou de la naiserie, le fameux Mac OS X que tu cites fonctionne grâce à un noyau linux...
Euh, tu réponds à qui ? Tu n'as donné aucun contexte...
Bref. Non, le noyau Mach utilisé dans Mac OS X n'est PAS un noyau Linux.
-- "Je deteste les ordinateurs : ils font toujours ce que je dis, jamais ce que je veux !" "The obvious mathematical breakthrough would be development of an easy way to factor large prime numbers." (Bill Gates, The Road Ahead)
On Wed, 17 May 2006, Jonas wrote:
Mdr,
Super le troll !
On m'avais habitué à mieux.
Dis moi mon grand, tu n'aurais pas un peu trop picolé...
Vas te reposer un peu çà te fera du bien.
Quand on ne sait pas de quoi qu'on cause, on cause pas...
C'est mieux pour tout le monde, parce que là tu m'as mis de mauvaise
humeur pour les DIx minutes qui suivents. Je te rassure au dela des dix
minutes, je vais pouffer de rire en moquant des abrutis qui pense
encore que windows est un système d'exploitation, alors qu'il n'est
qu'un vague gadget inutile.
A titre d'info, Ô grand gourou de la naiserie, le fameux Mac OS X que
tu cites fonctionne grâce à un noyau linux...
Euh, tu réponds à qui ? Tu n'as donné aucun contexte...
Bref. Non, le noyau Mach utilisé dans Mac OS X n'est PAS un noyau Linux.
--
"Je deteste les ordinateurs : ils font toujours ce que je dis, jamais ce
que je veux !"
"The obvious mathematical breakthrough would be development of an easy
way to factor large prime numbers." (Bill Gates, The Road Ahead)
Dis moi mon grand, tu n'aurais pas un peu trop picolé... Vas te reposer un peu çà te fera du bien.
Quand on ne sait pas de quoi qu'on cause, on cause pas... C'est mieux pour tout le monde, parce que là tu m'as mis de mauvaise humeur pour les DIx minutes qui suivents. Je te rassure au dela des dix minutes, je vais pouffer de rire en moquant des abrutis qui pense encore que windows est un système d'exploitation, alors qu'il n'est qu'un vague gadget inutile.
A titre d'info, Ô grand gourou de la naiserie, le fameux Mac OS X que tu cites fonctionne grâce à un noyau linux...
Euh, tu réponds à qui ? Tu n'as donné aucun contexte...
Bref. Non, le noyau Mach utilisé dans Mac OS X n'est PAS un noyau Linux.
-- "Je deteste les ordinateurs : ils font toujours ce que je dis, jamais ce que je veux !" "The obvious mathematical breakthrough would be development of an easy way to factor large prime numbers." (Bill Gates, The Road Ahead)
talon
sansflotusspam wrote:
ça PEUT marcher comme ça, mais ça dépend énormément du programme et du programmeur ; les programmeurs window$ utilisent le plus souvent des "générateurs" ou pseudo-générateurs (visual-machin, windev, etc) qui ont la triste manie de mettre les appels systèmes "en dur" dans l'exe. conséquence : quand l'exe appelle une machin.dll, c'est obligatoirement c windowsmachin.dll, la c:tototatamachin.dll ne sera jamais cherchée ni trouvée.
Je n'ai pas autant d'expérience, je me suis contenté de programmes trés courants sous Windows, tels que Firefox, OpenOffice, bsplayer et ses codecs, etc. et ils ne m'ont jamais posé de problème.
ça PEUT marcher comme ça, mais ça dépend énormément du programme et du
programmeur ; les programmeurs window$ utilisent le plus souvent des
"générateurs" ou pseudo-générateurs (visual-machin, windev, etc) qui ont la
triste manie de mettre les appels systèmes "en dur" dans l'exe.
conséquence : quand l'exe appelle une machin.dll, c'est obligatoirement c
windowsmachin.dll, la c:tototatamachin.dll ne sera jamais cherchée ni
trouvée.
Je n'ai pas autant d'expérience, je me suis contenté de programmes trés
courants sous Windows, tels que Firefox, OpenOffice, bsplayer et ses codecs,
etc. et ils ne m'ont jamais posé de problème.
ça PEUT marcher comme ça, mais ça dépend énormément du programme et du programmeur ; les programmeurs window$ utilisent le plus souvent des "générateurs" ou pseudo-générateurs (visual-machin, windev, etc) qui ont la triste manie de mettre les appels systèmes "en dur" dans l'exe. conséquence : quand l'exe appelle une machin.dll, c'est obligatoirement c windowsmachin.dll, la c:tototatamachin.dll ne sera jamais cherchée ni trouvée.
Je n'ai pas autant d'expérience, je me suis contenté de programmes trés courants sous Windows, tels que Firefox, OpenOffice, bsplayer et ses codecs, etc. et ils ne m'ont jamais posé de problème.
