Le 19/01/2015 à 14h 05

La très large majorité du parc Android aujourd’hui, c’est celui qui est fournit par le constructeur du smartphone en question qui contient entre autres :

• les google services (close-source),
  


• l’API Google (close-source),
  


• les drivers des constructeurs (majoritairement close-source).
  
  Et ce qui est libre c’est majoritairement pas fait par eux (kernel linux + libs bas niveau standard).

Le 19/01/2015 à 13h 55

L’intérêt de divulguer les failles quand elles sont corrigées, c’est la connaissance. Typiquement si tu veux faire de la recherche en sécurité, comprendre comment les autres ont fait avant toi c’est un bon moyen d’apprendre plus vite et de trouver des méthodes plus générales.

Les divulguer avant qu’elles soient corrigées, deux possibilités : si tu les vends, ça peut valoir cher, si tu les mets en ligne gratuitement, ça montre que tu as la plus grosse.

Le 19/01/2015 à 13h 53

AeRoX a écrit :

 je serais assez curieux de savoir si toutes les failles sur leurs OS sont corrigées en moins de 3 mois d’ailleurs. Vu qu’ils diffusent eux mêmes les infos et que (à ma connaissance) personne d’autre ne le fait, de leur côté c’est facile d’être toujours à l’heure sur les corrections.


Ben disons qu’ils ont le beau rôle : une majorité du Kernel n’est pas écrit par eux mais par les mainteneurs de Linux, une autre large majorité de même kernel, c’est les drivers qui sont écrits par les constructeurs, donc déjà sur ce point si une faille apparaît c’est cette partie de code qui est assez massive, ils ont juste à dire que c’est pas eux de le faire.

 Pour le reste j’ai du mal à savoir quel volume de code sort réellement de leurs mains (à part les Services Google mais desquels on ne sait approximativement rien).

Le 19/01/2015 à 13h 45

Les distributions font de l’intégration en très large majorité, pas de la correction de faille.

Corriger une faille, c’est autre chose qu’intégrer un patch. D’abord faut trouver pourquoi la faille existe, il faut voir si c’est une erreur dans les specs ou si c’est une erreur dans le code. Il faut trouver comment faire la correction, l’effectuer, et voir si elle n’introduit pas de nouveaux comportements tordus en rejouant les tests avec un certain nombre de configurations. Alors sur un OS qui doit être de l’ordre de 80 millions de lignes aujourd’hui (au pifomètre par rapport à l’accroissement de ce genre de système, et du fait que 7 c’était environ 70 millions de lignes) c’est pas franchement de la tarte.

Le 19/01/2015 à 13h 22

http://www.zone-numerique.com/android-4-3-une-faille-qui-ne-sera-pas-corrigee-par-google.html

Et la méthode de Google pour se laver les mains c’est “ben c’est pas de notre faute, c’est les constructeurs qui mettent pas à jour vers 4.4”. (j’ai pas poussé plus loin mais ça doit pas être la seule).

Le 13/01/2015 à 07h 48

Ne pas avoir de Ctrl+F c’est la plaie. Et chercher dans un bouquin de 1500 pages, c’est chiant.
J’ai pas retrouvé tous les passages exacts mais j’ai celui-là :

A.Tanenbaum - Modern Operating Systems. “When essentials libraries are included [ndlr : grosso modo, l’API Win32 et le .Net minimal], Windows is well over 70 million lines of code” (ça exclut bien sûr les choses comme Windows Media, Internet Explorer, etc … qui feraient exploser littéralement le nombre de lignes). Les chiffres sont basés sur Windows 7, il n’y a pas d’info pour 8, mais a priori avec les nouvelles API + résidu historique, ça a dû gonfler pas mal.

Donc grosso modo, sur la code base Windows 7, c’était de l’ordre de 70 millions de lignes. Par contre je n’arrive pas à retrouver le passage vraiment intéressant qui concernait le kernel.

Le 12/01/2015 à 19h 51

Konrad a écrit :

Bref, c’était une affirmation en l’air ou tu as un lien pour étayer tes dires ?


J’essaie de retrouver le passage dans le dernier Tanenbaum demain (je l’ai pas sous la main).

Le 12/01/2015 à 19h 07

Konrad a écrit :

Et non, a priori tu as tort :

• Windows 7 : 40 millions de lignes de code
  


• Debian 5.0 base : 65 millions de lignes de code.
  
  Si tu as des sources pour appuyer tes dires, merci de les citer.
  
  
  Debian base contient un quantité effroyable de drivers matériel. Ce n’est pas le cas de Windows.

Le 12/01/2015 à 17h 23

Ballos a écrit :

Message à Microsoft : Engagez du personnel et cessez de vous plaindre, car vous semblez ridicule  à toujours être le seul à vous plaindre quand le reste de l’industrie travaille à protéger ses outils..

 Pourtant ils ont des marges de plus 42% selon leurs derniers bilans, bien au delà de Apple qui pointe autour de 37%, c’est pas l’argent qui manque, sauf quand on s’en fout un peu  de ses clients..


Ouais bien sûr, c’est bien connu, mettre plus de personnes sur le même travail le fait avancer plus vite. De même que mettre 9 femmes sur une même grossesse permet d’avoir un enfant en un mois.

Réaliser un build fonctionnel sur un monstre de code comme Windows, c’est pas de l’ordre du facile.

 Pire encore si on a une importante faille qui est due à un défaut structurel, la quantité de code à modifier peut être malheureusement assez énorme. Et dans un projet de cette taille, tout le monde ne connaît pas toute la machine, donc s’il faut mettre un gros paquets de personnes différentes (qui ne font pas que corriger des bugs toute la journée, hein, ça peut paraître dingue mais en vrai il y a plein d’autres tâches à réaliser) sur un même bug impactant une vaste portion de code et demandant de repasser une grande quantité de tests de non-régression (en plus du nouveau test à ajouter pour s’assurer que la faille est corrigée), oui, ça peut prendre du temps.

3 mois si la faille est très complexe, ça ne semble pas complètement surréaliste, surtout pour un OS qui est arrivé à la complexité de Windows (et oui, c’est plus gros que Linux, et non Linux est loin d’être un exemple de beau code, il a les mêmes tares que les autres).

Le 06/01/2015 à 09h 43

David_L a écrit :

Comment ça ? Le principe du cast c’est que c’est l’appareil qui va chercher le son, pas le téléphone/tablette qui lui envoie ;) 


Euh, tu joues un peu trop sur les mots. Quoi qu’il arrive, le téléphone/tablette enverra des données. La question est  de savoir s’il y a un pré-traitement avant l’envoi et s’il est destructif (comme c’est le cas avec le bluetooth par exemple).

Le 18/12/2014 à 14h 34

Et bien sûr cela n’a aucun rapport avec le fait que les activités ludiques et éducatives soient orientées dans ce sens.
Évidemment, on peut trouver une tendance générale qui fait que les garçons préfèrent aller dans un sens et les filles dans l’autre. On les a éduqué comme ça, de même que nos parents nous ont éduqués comme ça. C’est une tendance qui commençait à s’inverser progressivement mais que le marketing pousse de plus en plus fort pour continuer à axer facilement notre consommation.
Le problème n’est pas de vouloir mettre tout le monde en gris, le problème est que tout le monde ait la possibilité d’utiliser n’importe quel couleur quel que soit son sexe sans que le garçon soit une femmelette et la fille un garçon manqué. C’est un peu différent.

Le 12/12/2014 à 07h 41

HarmattanBlow a écrit :

Voir l’article :
De plus, chaque jeune devra être capable, à l’issue de sa scolarité obligatoire, « de réaliser de petites applications utilisant des algorithmes simples ».

Irréaliste et stupide.


Irréaliste, certainement pas. Stupide, voir mon avis dans les commentaires précédents.

Après ça dépend ce que tu entends par “application utilisant des algorithmes simples”, mais faire une calculatrice (avec GUI), un mini-jeu de labyrinthe ou encore un petit snake, c’est largement du niveau d’un collégien si on arrête de le prendre pour un con et qu’on lui explique patiemment comment ça marche.

Le 11/12/2014 à 14h 08

Ce n’est pas parce qu’on ne sait pas encore comment enseigner convenablement l’informatique dans les premières années d’apprentissage (primaire ?, collège ?, lycée ?) qu’on ne peut pas essayer. En particulier, comprendre comment on peut faire pour trier des éléments, ben c’est pas si compliqué.

Le fait de ne pas enseigner l’informatique plus tôt est un vrai problème. 

Je veux dire, on enseigne la physique, la chimie. Au primaire : éveil aux sciences, petites expériences simples. Au collège : un tout petit peu de théorie, des expériences plus intéressantes. Au lycée : on commence à faire des choses intéressantes, avec un bagage théorique plus conséquent, la liaison au mathématiques formelles, etc …

Mais l’informatique, non. Le résultat c’est quoi ? Ben pendant qu’en université, en école d’ingé, dans les matières comme la physique, la mécanique, etc … on étudie des concepts très avancés parce qu’on a le bagage intellectuel pour le faire (relativité générale, mécanique des fluides, physique nucléaire, etc …).
En informatique on est bloqué à expliquer c’est quoi une boucle ? C’est quoi la mémoire ? Comment on écrit un programme ?
 
Pour résumer, en physique/chimie/mécanique/whatever, en 5 ans on passe les gens de “je sais vaguement ce que c’est mon domaine” à “je suis en pointe dans mon domaine avec cette spécialité (que j’ai rapidement pu choisir en toute connaissance de cause)”.
Alors qu’en info, en 5 ans, on doit faire passer les gens de “j’ai aucune idée de ce qu’est un programme” à “je suis en pointe dans mon domaine (que je ne connaissais même pas il y a 5 ans), avec cette spécialité (que j’ai choisi un peu comme j’ai pu)”.

On voit qu’il y une des tâches qui va un peu moins bien se passer au premier coup d’oeil …

Le 08/12/2014 à 14h 05

Obidoub a écrit :

La vache si chaque conteneur demande 1GB de ram ça risque de bloquer assez vite…
Ca sent le mini-OS super lourd.
En lisant le titre j’ai cru à un “docker-like” ou a un “cgroup-like” mais en fait ça sent l’usine à gaz.


Faudrait réviser un peu le cours sur la mémoire virtuelle ;) .
(Et si c’est pas virtuel alors c’est mauvais).

Le 26/11/2014 à 08h 22

Il y a une grosse différence entre “respecter un contrat qui ne convient pas au client”, auquel cas le client peut effectivement aller voir ailleurs si ça ne lui plaît pas, et “ne pas respecter un contrat”, auquel cas le client paye pour un service dont on lui dit qu’on va lui assurer alors qu’on ne le fait pas.

Le 22/10/2014 à 14h 56

feuille_de_lune a écrit :

Si le PC reste la plateforme la plus “plébiscitée”, alors pourquoi des portages toujours aussi " /> dessus ?


Sur un plan strictement performances, se casser le cul à faire un portage qui déchire n’apporte rien à l’éditeur. De toute façon, même en gardant un code optimisé pour console la majorité des PCs feront tourner le bousin sans trop de soucis (modulo quelques configurations au moment du build pour prendre en compte la taille moyenne des caches sur PC).

Sur un plan strictement jouabilité/expérience, les joueurs achèteront quand même, donc l’éditeur ne se cassera pas non plus le cul à faire un truc conçu spécifiquement pour PC (sans compter les joueurs PC qui jouent à la manette).

Le 15/10/2014 à 08h 23

“sans virtualisation”.

…

Ben et l’OS il fait quoi ? " />

Le 23/09/2014 à 09h 31

ActionFighter a écrit :

Très discutable en effet. Il ne semble pas opportun pour le bien de la justice de légitimer l’adage “œil pour œil, dent pour dent”….


En même temps, les humains ne sont pas justes et la justice est rendue par des humains. Et même comme ça, c’est quoi être juste ? C’est quand on choisit une peine à la valeur de la souffrance subie ? Avec quoi on estime tout ça, avec un souffrance-mètre et un peine-mètre ?
Des justices, il y en a des quantités différentes selon les cultures et les pays, dans le meilleur des cas, elles sont inadaptés, et le pire des cas, vaut mieux pas en parler.


FunnyD a écrit :

toute personne émotionnellement concernée est de fait disqualifiée car son jugement en est forcement perverti." />


Pour juger de la souffrance émotionnelle d’autrui (et toute agression contient cette dimension, qui est généralement la plus destructrice), tu ne peux pas être complètement déconnecté, à moins d’avoir le souffrance-mètre sus-cité.

Le 10/09/2014 à 18h 01

Ce que j’aime avec les news Apple c’est que les extrem-haters finissent par être aussi (voir plus) idiots et plus nombreux que les extrem-lovers.
On choisit un smartphone selon tes besoins, tes moyens et tes goûts.

Le 23/07/2014 à 08h 55

tazvld a écrit :

Sinon, il y a Android qui est open source.


Le code des “Services Google” n’est pas OpenSource lui, mais ils ont approximativement accès à tout le contenu du téléphone, donc si on veut faire fuir des informations par là, on peut. Reste la solution de passer sur des solutions comme les ROMs Cyanogen en consorts mais ça concerne quel pourcentage des utilisateurs ??

Le 13/06/2014 à 08h 37

Neeko a écrit :

Je ne comprends pas qu’on puisse reprocher aux jeux d’aujourd’hui d’être plus bugués, sachant leur complexité, et surtout la possibilité d’être mis à jour. Un jeu NES bugué, c’était de l’argent perdu. Ici, on peut espérer un correctif.


Si on peut leur reprocher pour quelques raisons assez simple (certaines déjà évoquées) :

• entre il y a 25 ans et maintenant, les équipes sont passées de quelques personnes à quelques centaines de personnes. A noter : le moteur du jeu, c’est plutôt quelques dizaines grand max.
  


• les budgets pour le développement sont devenus collossaux mais c’est à l’image du nombre de joueurs.
  


• les outils permettant de le développement ont eux aussi évolués. Faire un programme très complexe aujourd’hui est à peu près du même niveau de difficulté que faire un programme assez complexe il y a 25 ans.
  


• la réutilisation est aujourd’hui bien plus facile : une boîte achète ou produit un moteur de jeu (dans le cas de EA produit) et le réutilise pour une foule de jeu différents. Je n’ai rien contre la réutilisation des moteurs, c’est au contraire la preuve qu’on est capable de produire du matériel qui peut servir plus d’une fois à des tâches légèrement différentes et c’est un très bon point. Mais le fait est qu’on ne sort pas un jeu alors qu’il n’est pas prêt. Quand on choisit de faire un moteur, on sait que c’est un investissement sur le très long terme, il faut être prêt à encaisser la charge.
  
  Et pour finir du côté de EA : pour BF4, on parle d’un jeu sorti en Octobre et qui était injouable en multi (dommage pour un jeu multi …) et dont le netcode n’est toujours pas réglé et qui contient toujours des bugs de physique monstrueux. En huit mois. Ce n’est pas rien.

Le 20/05/2014 à 09h 20

Winderly a écrit :

Ça tombe bien la mémoire vive est sensée servir à ça.
Si tu dois charger un jeu entier en RAM avant de l’exécuter, où est l’optimisation ?


Le jeu installé sur la machine pèse dans les 30Go, je pense pas qu’ils stockent les textures décompressées sur le disque. A supposer que dans les scènes les plus what-the-fuck, ils n’utilisent que 5% des textures/mesches/sons/whatever, 1Go (pour arrondir) décompressé dans les buffers ça peut déjà être méchant surtout quand il faut rajouter les calculs de rendu. Généralement, tout ça passe par des algos de compression/décompression optimisés pour GPU, mais ça reste pas de la tarte.
Et 30Go c’est ce qui sort aujourd’hui, à voir ce qu’on produira comme jeu dans 2 ans.


Zulgrib a écrit :

Tu fais en sorte que ta texture soit une formule mathématique en lieu d’un fichier de 4Go ? Ta formule mathématique va pas faire 4Go n’est-ce pas ?


Ben, une fois calculée pour en faire son affichage, elle fera largement plus que le poids d’une formule (pas 4Go effectivement). Puis comme ça a été dit avant on peut pas tout créer avec des formules.

Le 20/05/2014 à 06h 53

yAMiGoHaN a écrit :

Ils ont craqué les mecs chez Crytek… 8 Go c’est largement suffisant aujourd’hui, et dans 5 ans ça le fera aussi. On est sur console les gars, pas sur pc, l’optimisation ça existe " />


L’optimisation en espace a ses limites … Le problème ici, c’est que les textures HD, si tu en mets vraiment beaucoup ça finit par prendre vachement de place. A moins d’amuser à charger/décharger les textures depuis le disque à la volée, mais là c’est plus la peine de chercher les performances …
Après si tu considères que l’optimisation façon console (on pourrit les graphismes pour prendre moins de place et aller plus vite, voir on baisse la résolution à la volée) est une technique valable, effectivement, on peut optimiser. Mais chez moi optimiser c’est aller plus vite et/ou prendre moins de place pour obtenir un résultat équivalent.


Fuinril a écrit :

Mes profs de prog, il y a plus de 10 ans, regrettaient le temps de l’ASM et des optimisations de derrière les fagots…. tout en reconnaissant que les compilateurs faisaient du bien meilleur boulot, bien plus performant, tout en proposant une rapidité et un confort de codage sans commune mesure….


Dans le cadre de l’ASM, c’est de la micro-optiimisation. Aujourd’hui effectivement on connaît suffisamment bien les techniques de simplification, parallélisme d’instruction pour que les compilos puissent produire du code ultra rapide sur de courtes portions de code.
Il n’empêche que si tu veux utiliser correctement ta bande passante (parce que c’est là les vrais pertes de vitesse, c’est pas dans la vitesse d’exécution du proco), il faut se sortir les doigts du cul pour avoir un rendement de la mort qui tue " /> .
Mais comme Crytek le dit, la limite sur ces consoles, c’est pas la bande passante, c’est l’espace dispo pour stocker des choses.


Winderly a écrit :

Il y en a qui y arrivent avec moins de 8 Go, donc c’est possible.


Si tu lis bien, Crytek annonce avoir dû beaucoup travailler sur ce jeu pour que ça marche bien. Ils n’ont pas dis qu’ils n’avaient pas réussi, ils ont dis que ça leur avait demandé beaucoup de travail. Et que dans le futur, ça deviendra encore plus difficile (plus de textures, plus grosses, etc …).

Le 13/05/2014 à 11h 48

jb a écrit :

Je sais pas trop pourquoi c’est drôle…


A vrai dire, ce serait même plutôt triste, la majorité des compilos libres ont le plein support de C11.
D’ailleurs, ils sont encore loin d’avoir tout C++11, d’aprèshttp://msdn.microsoft.com/fr-fr/library/hh567368.aspx , même les const-expr sont pas prises en charge, quand on sait que clang et g++ sont à peu près ok pour C++14, c’est dommage …

Le 17/04/2014 à 08h 40

v1nce a écrit :

On réussit à prouver des programmes de plus de 10 lignes maintenant ?


seL4, microkernel composé de 9000 lignes de code C, prouvé avec Isabelle/HOL.

Le 17/04/2014 à 06h 44

Edtech a écrit :

• Faire des tests unitaires prenant en charge le maximum de cas d’erreur possibles.
  […]
  
  
  
  
  • Mise en place de tests automatisés globaux quand c’est possible.
    
  
  
  • Tests en conditions réels.
    
    
    Mieux vaut ne pas avoir de soft avec du (vrai) parallélisme alors. Parce les synchros sans lock foireuses, elles feront des conneries allé, une fois sur 1000, mais dans un soft secure c’est déjà de trop.
    Les tests c’est trop facile, donnez moi la preuve ! " />
  
  

Le 09/04/2014 à 11h 29

charon.G a écrit :

C’est possible sur des projets de petites tailles comme les hyperviseurs mais sur un projet comme un os, difficilement réalisable.


J’ai jamais dit que c’était facile " /> .
Après augmenter sa capacité à créer du code non-managé sûr permet de s’affranchir du management quand son surcoût n’est pas acceptable par rapport au coût de l’opération “réelle” (si on peut dire). Cela permet d’avoir plus de liberté pour trouver un juste milieu.

Le 09/04/2014 à 11h 09

charon.G a écrit :

Il n’y a pas que ça il y aussi les personnes qui viennent t’expliquer qu’on peut écrire sécurisé en C++ et qu’il suffit de relire le code pour limiter les failles. Il y’avait encore une news la dessus il y a quelques jours sur .NET…


Je suis d’accord sur un point : penser qu’une relecture poussée suffira à trouver et corriger toutes les failles est idiot.
En revanche, je suis effectivement convaincu qu’on peut écrire du code sécurisé dans n’importe quel langage. Le problème c’est se donner les moyens de le faire. Cela passe par un travail de formalisation qui est loin d’être trivial mais reste de l’ordre du faisable.

Le 09/04/2014 à 10h 58

typhoon006 a écrit :

C’était sur OpenSSL qu’il y avait des soupçons de backdoor à un moment.
Et que le code avait était relu pour plein de monde.
Et personne a vu la faille à ce moment là…il a du être bien relu le code " />


Ouais d’ailleurs en relisant un code correctement on trouve tous les bugs. D’ailleurs, la détection de bug c’est complètement trivial.

Le 08/04/2014 à 07h 06

slave1802 a écrit :

Essayes avec une clé USB…


Sur un vieux PC, il y a (très) peu de chance que tu puisses booter en USB.

Le 07/04/2014 à 08h 08

levhieu a écrit :

Il est multi-cœur le CPU de la Xbox 360 ?
(vrai question par quelqu’un qui n’a jamais eu aucune console, ni de jeu sur PC d’ailleurs)


Wikipedia - XBox 360 - Caractéristiques.

Le 07/04/2014 à 07h 59

Nithril a écrit :

Cela peut se faire via un transcodage des instructions. cf. Anikam, Apple l’a fait ;)


Il y a des intructions Power pour lesquelles tu ne peux pas trouver de comportement équivalent en x86, simplement parce que le Power a un modèle mémoire plus faible que celui du x86 (et donc plus permissif). Quand tu travailles en mono-thread, pas de soucis. En multi-thread, c’est une autre histoire.
Quand Apple a fait ce portage, le multi-threading n’était pas encore très en vogue et les synchronisations se résumait à du lock. Aujourd’hui on exploite les modèles pour faire de la synchro sans mutex. Si les jeux exploite les faiblesses du modèle Power pour faire certaines opérations, ce n’est pas forcément possible en x86.

Le 05/04/2014 à 16h 17

finaud a écrit :

c’est beau comme SFR vient de mettre a genoux Bouygues obligé d’être céder a Free maintenant !" />


Absolument pas, c’était sous réserve que l’opération d’achat d’SFR soit effectué. Ce n’est pas le cas donc pas de cession.

Le 05/04/2014 à 11h 06

Paulo Paulo a écrit :

Je l’ai vu, j’ai tout de suite senti l’arnaque, il n’y a pas le logo “Page vérifiée” " /> Et pourquoi appelleraient-ils leur page bouyguestelecom au lieu de Bouygues Télécom…


Dans les trucs plus grillés, il y avait le nom associé à l’@ .

Le 02/04/2014 à 06h 48

knos a écrit :

Alors ils n’ont même pas attendu la dernière mise a jour? Etrange. C’est le risque que l’attaque soit contré par ms.


C’est les premiers tests pour voir si le matériel tient la charge et que les performances du malware scalent bien sur pas mal de machines (et l’occasion de patcher la bête " /> ).
Comme ça, quand la dernière MaJ sera passée, il y aura plus qu’à exploiter une faille et lancer la bête.

Le 24/03/2014 à 21h 23

Non je ne veux rien vous dire, à part ce que je viens de vous dire c’est à dire “je ne peux rien vous dire”. Je peux vous dire “je ne peux rien vous dire”, mais je ne peux vous dire que… “je ne peux rien vous dire”. Mais j’aimerai bien vous le dire mais je peux pas. Enfin à part “je ne peux rien vous dire”, c’est à dire… enfin je ne peux rien vous dire. Sauf… je ne peux rien vous dire.

Le 24/03/2014 à 08h 41

Mais on n’a jamais dit qu’ils essayaient de tuer les franchises, on a dit qu’ils y arrivaient, c’est pas pareil.

Le 19/03/2014 à 14h 58

Franchement maintenant que tous les forfaits (ou presque) proposent de l’illimité SMS, les abréviations de ce genre ne sont plus nécessaires …

Le 25/02/2014 à 13h 06

Maxim Killigan a écrit :

Ce code est vraiment très, très, très laid, de toute façon…


C’est un cas très loin d’être rare.
Par ailleurs, ce genre de procédure ( if (les_cas_d_erreur) goto fail; ) est une écriture relativement standard pour avoir une écriture des libérations en cas de problème pas trop lourdingue en C.

Le 25/02/2014 à 12h 28

Hebus a écrit :

Pourquoi autant de bruit ici?


Parce que n’importe quel analyseur de code, même pas très malin, te hurle dessus quand tu écris un truc comme ça parce que tu as un code mort.
Que le minimum pour qu’un code (surtout sur un protocole de sécurtié) soit validé en prod c’est le passer dans un analyseur de ce genre.
Et parce que Apple auront du mal à faire croire à qui que ce soit qu’ils n’ont pas ce genre d’outil.
A partir de là deux possibilité : le code n’a pas été analysé => boulot ni fait ni à faire, c’est honteux pour n’importe quelle entreprise, ou alors c’est intentionnel => ben le résultat parle de lui même …

Le 11/02/2014 à 15h 52

Bientôt compatible Google Glass " />

Le 11/02/2014 à 08h 21

elpetio a écrit :

2 la couche samsung cest ce qu’on fait de mieux sur android
ca lag un peu peut etre […]
bref je pense que les critiques ne sont pas justifiées en fait.


Ok, donc le fait qu’un téléphone à 4 coeurs (voir 8) avec un proce graphique de la mort qui tue se retrouve à ramer parce que la surcouche a été codée par des gorets est normal. Effectivement à ce tarif là, on peut tout justifier.

Le 07/02/2014 à 13h 27

Déjà faut pas se plaindre, j’ai tourné sur la nightly Modern Ui pendant des semaines et la molette ne fonctionnait pas (ou beaucoup trop peu). C’était un peu lourdingue. " />
Par contre la nouvelle interface est vraiment top " /> .
Manque plus que l’activation d’au moins quelques plugins, Youtube refuse que je passe en HTML5 sur cette version du navigateur " />

Le 28/01/2014 à 07h 51

Pauvres petits investisseurs spéculateurs, c’est vraiment dur la vie " /> .

Le 17/01/2014 à 13h 02

unCaillou a écrit :

Quand on achète une cafetière ou une voiture, tant qu’elle fonctionne toujours, même 10 ans après, y a aucune raison d’en changer.
Mon PC c’est pareil, 10 ans après il tourne toujours bien.


Ah mais la machine elle tourne très bien. Elle fait exactement ce qui lui est demandé. Si on a un virus qui a demandé à la machine d’exploiter telle faille, elle fait exactement ce qui lui est demandé. Si il demande à transférer les données à l’étranger à la suite de ça, elle fait exactement ce qu’on lui a demandé.
La machine fonctionne très bien.

Le 17/01/2014 à 12h 48

Snakeseater a écrit :

Les entreprises n’ont jamais cru que XP serait éternel, vu que même pour un OS venant de sortir (W8 avec son update 8.1 par exemple) on sait la date de fin de support.

http://windows.microsoft.com/fr-BE/windows/products/lifecycle

Je serait de toute façon curieux de savoir quel entreprise tourne encore avec un noyau linux vieux de plus de 10 ans " />


Ce que je veux dire par là, c’est que la plupart ont décidé d’avoir XP comme plateforme, jusque là pourquoi pas. Puis, dans un second temps de s’équiper auprès de différents fournisseurs en logiciel soit tout faits, tournant sous XP, soit des commandes avec un cahier des charges spécifiant comme plateforme : XP, jamais que le support ( … et portage) devrait être assuré par la suite sur d’autres plateformes (ben oui le futur quoi).
Résultat aujourd’hui, il y a des boîtes qui ont les points liées parce que d’un côté Microsoft arrête de supporter XP et de l’autre les fournisseurs de logiciels ont décidé de ne pas pousser le support des logiciels vendus au delà d’XP.

Le 17/01/2014 à 12h 29

Snakeseater a écrit :

Ah, ces bobos complètement à côté de la réalité de l’entreprise…


Ah ces entreprises qui étaient convaincues que le support d’XP serait éternel.

Le 16/01/2014 à 12h 06

DayWalker a écrit :

C’est donc de l’incompétance si matériellement XP est compatible avec certains matériels hardware, et pas 7 ?


Ben en même temps si le constructeur ferme son matériel, c’est pas à l’OS de fournir le driver, c’est au constructeur, donc c’est eux les abrutis dans l’histoire.


DayWalker a écrit :

Donc oui, on a des XP (et même du win 3.1, voir du DOS, avec des cartes ISA par exemple !), et ce n’est pas par incompétance, mais parce que CA MARCHE et qu’on a pas envie de raquer pour autre chose qui va nous faire perdre du temps pour que ca marche aussi bien (et encore, si théoriquement on peut upgrader notre matériel)


Le problème de cette façon de voir les choses, c’est que ça marche jusqu’à ce que ça ne marche plus. Et le jour où plus personne sait comment réparer, on est pas dans la mouise.

Le 15/01/2014 à 19h 05

Tant qu’il y a aura pas de preuve formelle :

• du proco
  


• du compilo
  


• de l’OS
  


• du prouveur
  C’est pas sûr " />

Le 10/01/2014 à 08h 04

CaptainDangeax a écrit :

le neurone n’oublie pas que tous ces langages, compilés en langage machine ou interprétés, sont fait pour être exécuté par des CPU qui n’exécutent QUE du langage machine (le CPU Java a fait long feu) …


Juste pour être bien clair, il n’a jamais été dit que le langage en question est interprété, managé ne signifie pas forcément interprété (typiquement les pointeur intelligents de C++ sont du managing mais c’est compilé).


CaptainDangeax a écrit :

… et que le problème des communications inter process ne connait que 2 solutions : le monolithique et sa soit-disant perte de sécurité, et le micro-noyau et son corrolaire, la perte de performances.


Ce n’est pas parce qu’on ne sait pas encore faire qu’on a des preuves que c’est impossible, ni qu’il n’existe pas de meilleure solution.