pasBill pasGates a écrit 16204 commentaires

Je ne crains pas du tout du chômage pour les programmeurs et analystes à cause du logiciel libre à moins que le logiciel libre soit d'une telle qualité et puissance qu'il ne requiert plus d'effort de mise en oeuvre et d'ajustement (les matheux appelleraient ça une preuve par l'absurde!).

Ben je serais ravi que tu aies raison, mais ce que j'ai vu du mariage programmation LL et business jusqu'a aujourd'hui ne m'a pas convaincu du tout. J'attends de voir une succession de reussites economiques qui montrerait que tous les crash de boites orientees LL n'etaient dus qu'a des mauvais plans/gestionnaires/... et pas au problemes economiques des LL eux-memes.

Les LL sont en train de brisé d'importants monopoles informatiques, obligeant les sociétés concernées (des colosses aux pieds de titanes) à réinvestir leur magot pour faire face à cette concurrence naissante, et qui dit investissement dit économie dynamique et stimulée .... car là le pognon circule .. et ça c'est bien.

La on est d'accord

Sans compter le fait qu'avec les LL, on remplace des licences au cout exorbitant par des employés en plus, des informaticiens ayant un certains savoir faire pour administrer un produit meilleur, pour au final aboutir au pire à un cout identique, mais avec une qualité accrue. Meilleur productivité pour les PME.

La par contre....
1) Tu crois vraiment que les societes vont reutiliser l'argent economise pour engager plutot que grossir leurs benefices ?
2) Le produit si il est sense reduire les couts de l'entreprise, c'est notamment en reduisant les besoins en main d'oeuvre(genre besoin de moins de sysadmin par machines,...), pas tres bon pour le chomage
3) Meilleur produit, ca reste encore a voir, certains segments oui, d'autres non

T'es un grand guignol.

D'abord, tu me dis que je ne suis pas place assez haut pour connaitre le contenu des contrats de MS.

Ensuite, tu prends pour argent comptant ce qu'un cadre d'IBM France dit, sans avoir la moindre idee de sa position ni de ses connaissances(et je peux te parier qu'a moins d'etre tres tres haut chez IBM, il ne connait pas les termes des contrats).

Sans parler du fait que les contrats, comme cela a deja ete montre, sont revus par un comite independant de MS qui interdit formellement cette pratique.

Je parlerais meme pas de l'anerie disant qu'en 2005/2006 IBM ne vendra plus de Microsoft(je suis sur qu'IBM sera ravi de voir 50% de ses ventes partir), a se demander qui est naif entre toi et moi.

C'est drole cette manie que tu as de ne croire que ce qui te plait.

Non, il y a un 3eme choix :

Ces boites sortent un patch pour leur soft qui marque uniquement les pages necessaires comme executables.

Pour la barriere trouee, ben tout l'OS est prevu pour tourner avec ce bit NX, donc tous les services venant de l'OS sont deja proteges(RPC, authentification, ...) ca fait deja pas mal, sans compter qu'enormement de softs ne generent aucun code a la volee et sont donc proteges aussi.

Il me semble que pas mal de choses ont change de ce cote la dans le kernel 2.6

Quand au pourquoi du comment avant, ben si je dis ce que pense je vais encore me faire allumer, donc je te laisse te faire ton opinion...

Ca depend de la maniere dont est architecture le programme.

Si c'est des process independants et qu'ils ne partagent pas de memoire, alors c'est 50Mo chacun.

Si ce sont des thread d'un meme process, c'est 50Mo pour l'ensemble

Si ce sont des processus independants qui partagent de la memoire, alors c'est un chiffre entre 50 et z processus x 50

Bordel, faut arreter la paranoia mon gars !

Tu veux que je dises quoi ? Que NT est plus jeune ? Qu'il est moins age ? Qu'il etait dans les couches quand Unix etait adolescent... ?

Comment veux tu que j'exprimes le fait reel que Unix a ete cree avant NT sans que tu te lances dans une crise de paranoia aigue sur les soi-disantes ramifications de mes paroles ?

Quel est ton probleme existentiel qui te fait croire que ce qui est plus age est moins bien ?

Tout ce que j'ai dit, c'est que c'etait la raison pour laquelle certains etaient sous Unix avant d'etre sous Windows, et il faut toujours qu'il y ait un fan d'histoires de complot pour traduire ce que je dis d'une maniere totalement detournee, c'est quand meme dingue.

Va prendre une aspirine et arretes d'imaginer que tout le monde en veut a ton Unix/Linux cheri, ca te fera du bien

Au contraire, les preuves je les ai donnees.

N'importe qui connaissant l'architecture de la stack BSD et connaissant l'architecture kernel-mode de NT sait parfaitement que ce ne peut pas etre la meme stack, meme modifiee, car il aurait fallu reecrire quasiment tout, c'est ca la preuve, a laquelle s'ajoutent le fait que les bugs des 2 stacks sont differents, que tu peux desassembler et verifier,...

alors que je ne connais pas beaucoup d'unixien qui s'enthousiasment tous les jours à travailler sur Windows.

C'est quoi un "unixien" ?

Un type qui etait sous Unix avant et qui est passe sous Windows ?

Ben Johannson en est un, moi aussi, et il y en a bcp d'autres aussi. Unix est plus vieux que NT, c'est normal que les gens qui ont plus de 20 ans aient touche a autre chose que NT a leurs debuts. Et je ne vois pas pourquoi ces gens devraient subitement ce mettre a detester les anciens systemes quand ils passent a un autre.

Pourquoi ? à une certaine époque, le discours était beaucoup plus "Linux ? connais pas, un truc de gamin, d'étudiant, c'est pas sérieux." Curieusement, quand ça commence à sentir le roussi, le langage devient plus,... mielleux

Desole, j'ai rien vu sur Linux ici, d'autre part MS n'a jamais dit de mal des BSD.

mais il est indéniable que le fud de Microsoft, ça existe, et qu'ils utiliseront toutes les armes disponibles pour combattre leurs concurrents.

Il est indeniable que ta paranoia existe aussi :+)

Ca depend de ce que font ces softs, je serai pas surpris si photoshop faisait de la generation de code a la volee pour generer ses filtres ou autres.

Maintenant tu as peut-etre raison et c'est un simple buffer overflow dans ces softs.

Le gros probleme, que valgrind ne resoudra pas non plus, c'est que l'on ne peut pas exercer tous les chemins dans le code, donc si ca se trouve Adobe utilise des debug heaps, etc... mais si ils ne touchent jamais a certains chemins du code dans leurs tests, ils ne trouveront pas certains bugs et seuls les utilisateurs les trouveront.

Quel bug ? Il n'y a aucun bug.

Si ces softs essayent d'executer du code cree a la volee, il faut soit :
- les mettre sur la whitelist
- que ces softs marquent ces pages comme executables

L'OS lui fait tout correctement, il voit un soft qui n'est pas sur la whitelist en train d'essayer d'executer du code sur une page marquee non-executable, il tue le processus.

Tu connais bcp d'utilisateurs de XP qui ont besoin de process avec plus de 10 connections en SYN_SENT au meme moment ?

Moi non

_C'est_ une preuve.

Le kernel gere les priorites differement, les allocations differement, NDIS et TDI font les choses de manieres tres differentes d'Unix,... Bref, rien ne colle.

Si cette preuve te plait pas, tu peux aussi desassembler le code et t'en rendre compte tout seul, regarder le comportement de la stack,...

ou puis-je télécharger le code source ?

Pas besoin des sources, tous les elements architecturaux, les interfaces en dessus et en dessous,... montrent que la stack aurait du etre reecrite pour pouvoir etre integree et avoir des perfs raisonnables.

Et comme ils ont déjà utilisé du code BSD pour des outils réseaux (ftp.exe) et ce de manière trés discrete ( il faut y aller à coup de strings), le doute subsiste...

Rien de discret, les copyrights sont dans le manuel et sur le site web.

Remarques, installer le SP2 de Windows XP sur un serveur Active Directory faut le faire, c'est pas donne a tout le monde :+)

Ce qui est con pour toi c'est que plusieurs personnes ici l'ont confirme.

Plutot que croire cette annerie de 512Mo, ca serait bcp plus simple que t'essayes toi meme et que tu voies la realite.

Au hasard, ma dev box n'a pas 512Mo de RAM, et elle tourne tres bien

Tu ne peux pas prouver le contraire. Tu ne peux pas prouver que ce qu'il dit ce sont « des conneries » Tu devrais donc toi aussi la fermer ?

Des preuves j'en ai plein.

Tu vas jeter un oeil sur le DDK, tu vas lire comment fonctionnent NDIS et TDI qui sont les couches entourant la stack TCP/IP, a quoi ressemble un miniport driver, l'architecture d'un driver sous NT, ce que sont les IRQLs, etc... et tu te rendras compte tout seul que la stack de BSD n'entre absolument pas dans l'architecture de NT et qu'il aurait fallu tout reecrire pour avoir une stack decente.

Si t'es pas convaincu, tu peux t'amuser a aussi ecrire des drivers pour NT pour te rendre compte que ce qui est ecrit est vrai.

C'est accessible a tout le monde, il suffit d'aller lire plutot que repeter des conneries sans fondement.

c'est une license qui permet de piquer du code (cf pile TCP/IP piqué a BSD par m$)

Dis moi, tu t'es promis de dire au moins une connerie par jour sur MS ces derniers temps ou bien ?

Prouves ce que tu avances ou alors _fermes la_ , tes conneries sont particulierement gonflantes.

A priori, si tu fais tout correctement oui.

Maintenant, on va pas pouvoir t'expliquer ton erreur de compil si tu ne dis pas ce qu'est cette erreur de compilation, on n'a pas tous des talents de voyant...

Si ce que tu viens de taper est ce que tu as dans ton code, le gros probleme evident que c'est que :

class BiduleContainer : public DataVector

ne specifie pas le type de DataVector(puisque c'est un template, faut preciser sur quel type il opere)

Genre faudrait faire :

class BiduleContainer : public DataVector< int >

Je ne nie pas que microsoft corrige ses faille c'est encore heureux, ce que je reproche ce sont les délais parfois anormaux et SURTOUT les écroulement de perormance qu'ils entraînes parfois... (ce fut le cas avec tout les sp chez moi autant 2000 que XP)

Le jour ou tu devras corriger un probleme complexe dans un soft utilise de 3000 facons differentes par 300 millions de personnes, tu commenceras peut-etre a comprendre a quel point ce n'est pas simple et pourquoi des fois ca demande du temps

Quand aux perfs, ben tu pourrais aussi te demander 2 secondes pourquoi cela n'arrive quasiment que chez toi, et que sur 99% des PCs ayant installe les SP il n'y a pas de degradation de performance.

bon allez on va arrêter de critiquer m$, puisque tu ne veut pas admettre que la qualitée et le sérieux de microsoft laisse sérieusement à désiré...

Contrairement a toi, je connais tres bien ce que MS fait et je connais parfaitement tout ce qui a trait aux service packs et patchs vu que c'est mon job. Le jour ou t'auras l'once d'un argument on en reparlera.

je m'exprime parfois très mal, mais tout ce que je dis se base sur de faits (même si souvent je n'arrive pas a retrouver les sources)

Des faits ? Lesquels ? Que 0.01% des machines de la planete ont un probleme de perf avec les service packs, et que tu n'as aucune idee si c'est du au HW, aux drivers, a des apps qui font des cochonneries,... ?
Moi j'appelles pas ca des faits, les faits c'est que quasiment personne ne se plaint des perfs apres application des service packs, aucune des reviews n'en fait mention, les newsgroups apres les sorties des SP3 et SP4 de W2k, SP1 de XP n'en font pas specialement mention,... A part toi et ta machine il y a qqe autres personnes qui s'en plaignent et c'est tout, une goutte dans l'ocean.

Bref, le jour ou tu sortiras de ta chambre et te rendra compte que la majorite des gens voient qqe chose de different, tu commenceras peut-etre a te demander ou est le probleme.

Que la classe de base soit un template ne change rien du tout, le compilo va etendre ton template avant de s'occuper de la classe derivee et tu te retrouveras exactement dans le meme cas que si la classe de base etait une classe basique.

Template ou pas = 0 difference, le resultat final est identique.

Les templates n'influent absolument pas sur le code genere a la fin, ils permettent simplement de ne pas reecrire 10x fois la meme chose.

M'est avis que :

1) Faudrait initialiser le semaphore avant de l'utiliser (semctl est ton ami)
2) Faudrait aussi initialiser buf.sem_flg dans up et down avant d'appeler semop

Le compilo va pas initiliaser ces valeurs pour toi et tu te retrouves avec des valeurs prises au hasard selon l'emplacement des buffers, d'ou le comportement aleatoire que tu vois.

Redhat, Novell, Mandrake, IBM,... c'est quoi sinon linux software entreprise ?

C'est a se demander si tu as une idee de qui developpe le kernel Linux

Plutot que sortir un amas de conneries a chaque fois que tu parles de MS / Windows, tu me montres une faille du kernel Windows qui n'a pas ete corrigee ?

Parce que bon, ramener tout Windows/MS a IE c'est un peu simpliste et trompeur hein.

Quand au fait qu'on ne fait rien, faut croire que t'as pas entendu parler du SP2 qui vient du sortir.

Plus tu parles moins t'es credible.

faudrais leur expliquer gentillement que les dévelopeurs linux c'est pas les abruti de chez ms...

Les abrutis ils t'emmerdent.

Les developpeurs Linux ont mis combien de temps pour corriger la faille ptrace ?