pasBill pasGates a écrit 16062 commentaires

les organisations de consommateurs

les entreprises

Marrant quand même, qu'est ce que l'APRIL attend ?

Ah oui, ils aiment bien casser du sucre, et diaboliser MS, mais quand il s'agit de mettre les pieds dans l'eau sur le sujet…

La kinect, bel exemple d'espion potentiel à domicile

Ah les accusations à la con….

Et ton téléphone c'est un ben exemple d'espion potentiel partout oû tu vas, mais visiblement cela ne te gène pas car ce n'est pas Microsoft qui le produit.

Reviens nous voir quand ton "potentiel" sera devenu "réel", parce que si on interdisait tout ce qui est "potentiellement" dangereux, on vivrait encore dans des caves.

Ben pour le coup c'est plutôt toi qui pointe du doigt les constructeurs.

Ce sont bien eux qui vendent ces machines aux supermarchés non ? Ce sont bien eux qui se retrouvent aux procès à chaque fois ?

De plus, t'es gentil, mais la preuve est entre les mains de MS et les constructeurs. S'il a raison les constructeurs ne la donneront jamais et MS n'a aucune raison non plus de le faire.

Vraiment ? C'est quoi ce petit jeu à la con ? On invente une accusation contre une boite, et on la répand et maintient pour forcer là-dite boite à révéler des informations confidentielles histoire de se disculper ?

C'est éthique ce genre de comportement ? Tu te fous de moi ?

S'il a tort pourquoi est-ce que les tarifs sont tellement secrets?

LOL. C'est quoi cette tournure de phrase pour accuser une boite d'un crime car elle garde ses tarifs business-to-business confidentiels ?

Tu veux venir me faire croire que toutes les autres boites en France et en Europe ont leurs tarifs de gros public ? Evidemment que non. Elles sont alors toutes coupables de coups bàs hein c'est ça ?

Du coup, tu demandes des preuves en sachant qu'on les lui refusera, c'est sacrément hypocrite!

Hypocrite ? Vraiment ?

Et accuser sans preuve c'est quoi ? Visiblement accuser une boite sans preuve ne semble pas te causer le moindre problème, mais demander des preuves te gène. On va dire que l'hypocrisie n'est pas chez moi mais plutôt chez toi.

La présomption d'innocence cela existe pour tout le monde, y compris pour les boites que vous n'aimez pas, y compris pour les boites qui font concurrence à votre OS chéri. Vous n'avez aucune justification à ignorer cette présomption quand cela vous arrange.

Je veux dire, si le coupable selon vous est Microsoft, pourquoi donc est-ce que vous n'arrétez pas vos accusations à la con et simplement allez intenter un procès à Microsoft ? Hein cela ferait pas de mal d'avoir un peu d'honnèteté intellectuelle.

Comme ça vos avocats pourront avoir une raison de demander ces contrats et les voir dans le cadre du procès, et si jamais vous étes dans votre tort Microsoft pourra se permettre de vous demander de payer leurs frais d'avocats.

On parlait de sociétés qui prennent des risques.

Les risques, ca marche parfois, parfois pas, c'est ce que la liste représente.

Je n'ai personellement absolument rien à prouver.

C'est toi qui accuses formellement Microsoft de certaines pratiques, à toi de les prouver.

Tu n'as aucune preuve mais juste des suppositions ? Ben arrètes d'affirmer des choses sans preuves.

Déjà avant il y en avait plein, pas grand chose n'a changé de ce côté là.

Genre …

TabletPC il y a 15 ans ?

HoloLens ?

IllumiRoom ?

Kinect ?

etc…

Non soyons sérieux, Google est très bon pour faire un joli marketing autour de trucs que d'autres ont déjà essayé (lunettes, voitures, …) mais au final il ne va pas forcément plus loin que Microsoft.

Par ex., j'entends par là qu'ils ne sont pas à la source de la reconnaissance d'image (par rapport au fait que tu cites la reconnaissance de squelette), ou à la source des consoles (par rapport à la XBox)

Euh… t'as déjà entendu parler de Microsoft Research ?

L'opinion et les préferences du petit ingénieur système ou du petit développeur de Microsoft, la direction s'en cogne (c'est pareil dans toutes les grandes entreprises).

Pas totalement faux et pas totalement vrai non plus.

Il y a de nombreux exemples de choses qui ont passablement changé dans MS et qui ont démarré depuis le petit dev (ok d'habitude c'est pas un junior, mais plutôt un gars avec plusieurs années d'expérience…)

Tout est affaire de convaincre sa hiérarchie étape après étape. C'est plus long à faire chez MS que dans une startup c'est sûr, mais c'est aussi bien plus rapide que le faire chez IBM.

Je doutes que cela change quoi que ce soit de ce côté.

Notamment car ce n'est pas de leur fait, mais du fait des constructeurs.

L'histoire du serveur email en fait est très peu importante…

https://theintercept.com/2016/11/09/democrats-trump-and-the-ongoing-dangerous-refusal-to-learn-the-lesson-of-brexit/

est à mon avis une très bonne explication de ce qui s'est passé (trop long pour un snippet, faut tout lire)

C'est con, ils ont plus de 50% du sénat et de la chambre des représentants aussi… Et il y a entre 20 et 30% des membres de la cour suprème à choisir ces prochaines années.

Bref, je suggères aux français de ne pas attendre l'année prochaine pour faire tout leur possible pour éviter la même chôse avec Marine.

Et je suis sérieux, les anglais croyaient que Brexit n'arriverait pas, les Américains croyaient que Trump n'y arriverait pas, … les prochains sont les Français.

La plupart des puces ARM sont 32bit donc bon, pas trop possible d'oublier :)

Oui. C'est un compromis mais uniquement pour permettre une solution générale. Tu peux certainement imaginer le délai comme étant un paramètre configurable par processus auquel cas tu as le meilleur des 2 mondes.

Oui mais tu remarqueras que la différence est très importante.

STL te permet de réessayer ou de sortir proprement. Il ne crashe pas sans te donner au moins une chance de gèrer la chose.

Non, c'est basé sur une autre idée :

• Mon soft n'est pas un gros bouffeur de RAM, et ne ré-essaie que pour les petites allocations.

Et c'est tout.

Partant de là, on assume que les autres processus ne vont effectivement pas bouffer TOUTE la RAM de manière permanente, auquel cas le système serait gelé de manière permanente de toute facon, et ces softs seraient coupable du gel.

T'as pas compris. Ce n'est pas mon soft qui gèle le système, c'est le système qui est gelé, peu importe la présence de mon soft ou pas.

Mon soft essaie d'allouer disons 16Kb, et fais un loop avec attente si il n'y arrive pas.

Si il n'y a pas 16Kb de dispo sur la machine de manière permanent, inutile de te dire que, avec ou sans mon soft, rien ne fonctionne sur la machine.

Cela arrive notamment si le tas est fragmenté. En fonction des heuristiques utilisées, un allocateur peut garder beaucoup de mémoire disponible qui ne sera pas allouable par d'autres processus.

De nos jours la fragmentation, pour les petites allocations, c'est fini.

Les allocateurs utilisent un systeme de free list ou un bloc est alloué, coupé en morceaux de la taille demandée, et un morceau retourné.

Le moment ou le morceau est libéré, il est mis sur la free list pour cette taille là, et quand un autre morceau de cette taille est demandé, si la free list n'est pas vide, le morceau est retourné de là plutôt qu'aller faire une allocation qqe part.

Résultat, il n'y a plus de fragmentation lors d'allocations de petite taille (sauf dans cas totalement pathologiques qui n'existent pas vraiment en réalité), les blocs restent compacts. Le seul cas ou tu as encore un tel problème est quand tu fais une énorme allocation, et tu remarqueras que mon allocateur ne fait pas de loop en cas de grosse allocation.

Mais imaginons un autre cas. Ta technique se répand, tous les softs s'y mettent.

Tu as bien raison !

Maintenant, la réalité en pratique est que ce n'est pas le cas et ne le sera jamais.

Mais au cas oû je deviendrais soudainement un exemple à suivre par toute l'industrie, je me contenterais de rajouter un compteur incrémenté à chaque tentative d'allocation ratée, et remis à zero en cas de succes. Si le compteur atteint un certain nombre, le soft sort proprement avec un exit().

Tout à fait, mais j'utilises cet allocateur en sachant évidemment comment mon soft alloue et gère sa mémoire.

Non, si tu épuises ta mémoire, tu dois au moins avoir la possibilité de décider si tu veux essayer de faire de la place et continuer plutôt que t'écraser.

Même la STL ne le fait pas que je sache (tu as un std::string dont tu consomme tout la capacité, il alloue 2 fois sa taille et va planter si ça marche pas, pas réessayer avec juste ce qu'il faut).

Non il ne va pas planter, il va lancer une exception. Ce n'est pas la même chose, et de loin.

ben en fait si. Tu peux marquer ton soft comme "prioritaire" histoire que OOM killer aille massacrer quelqu'un d'autre. Mais faut être admin.

• tu utilises tout ton espace d'addresse sous Linux, et ton malloc se ramasse à cause de cela. Tu ne check pas le NULL, te choppes un segfault immédiatement à l'accès. Tu regardes le core dump, et tu vois que tu faisais des mappings de fichier et oubliais de les libèrer, ou que tu ne faisais pas gaffe qu'un des fichiers que tu essaies de mapper est énorme et bouffe tout l'espace…

• sous Windows, ton malloc se ramasse car le processus d'à côté a décidé temporairement de tout allouer mais libère la plus grande partie 3 secondes après. Ton soft fait son malloc au milieu, se ramasse, tu regardes le crash dump et te rend compte que tu as oublié de gèrer le fait que malloc peut retourner NULL pour des raisons tout à fait valides sur une des plateformes que tu supportes.

vu qu'aucun soft n'est capable d'allouer (rappel: je ne fais cela que pour des allocations plutôt petites, si elles échouent systématiquement sur le long terme, c'est que plus grand chose ne fonctionne sur le système), ben l'utilisateur ne fera rien car le système sera gelé de toute facon… ssh / bash / RDP ne pourra rien allouer pour permettre à l'utilisateur de se connecter ou lancer des commandes, etc… donc bref, ca ne changera rien.