Le 23/07/2016 à 08h 10

Konrad a écrit :



). Il est effectivement prévu que le nombre de publicités dans le menu Démarrer double avec l’Anniversary Update de cet été.  





J’ai beau chercher, je ne vois aucune publicité dans mon menu démarrer. Pour moi, ce nombre peut même tripler si ils veulent…

Le 14/07/2016 à 10h 04

De l’asynchrone, j’en fais depuis 30 ans et le Z-80 des contrôleurs de l’époque (le multithread n’était pas trop répandu sur cette plateforme, mais il y avait des interruptions), donc c’est pas moi qu’il faut essayer de convaincre… Néanmoins, et pour nuancer mon propos, puisque manifestement il fait penser que je n’ai rien compris…



Le fonctionnement asynchrone est - comme tu le fais remarquer - utile quand on attend passivement qu’un processus extérieur fasse un traitement. Ce comportement est typiquement celui d’un client. Il arrive qu’on désire écrire un processus serveur qui agrège les résultats de plusieurs autres serveurs. Ce serveur prend donc, durant cette attente des résultats, lui-même une attitude de client. Un paradigme asynchrone est adapté à cela.



Par contre, là où le bât blesse, c’est que dès que tu as un workflow un peu complexe où tu alternes attentes passives et traitements lourds pouvant en plus être parallélisés, il devient vite compliqué de gérer ça, et tu as besoin de points de rendez-vous qui ne sont pas aisés à exprimer avec de “simples” fonctions de callback et qui, selon mon expérience, sont plus faciles à écrire et donc moins fragiles quand tu exprimes ce que tu attends directement dans un thread (j’ai pas dit que c’était impossible en asynchrone, je dis juste qu’il est beaucoup plus facile de perdre le fil du workflow - et la lisibilité du code dans ce contexte est cruciale).



Notamment un truc comme notre implémentation du protocole ASTM-1381 qui prend 8 pages quand c’est exprimé en asynchrone avec une machine à états (sans même gérer tous les cas), a pu se réécrire via un thread comme (de mémoire) :



   while (retrycount < 6) {

      send block

      switch (read character) {

       case ACK : return true;

       case NAK : retrycount ++; break;

       case EOT : *interrupt = true; return true;

       case TIMEOUT : return false;

       default : flushInput(); retrcount++; break;

     }

  } 



Ce morceau-là se prêterait encore assez bien à un await AsynchSendBlock() et await AsynchReadChar() mais si c’est juste pour faire immédiatement un await d’un asych, autant faire directement un thread…

 

Le 14/07/2016 à 07h 19

brazomyna a écrit :



Donc si je comprends bien, la situation actuelle c’est d’avoir les mots de passe hardcodés dans le javascript refilé au client, qui est mis à dispo dans l’ensemble de l’intranet.



A ce niveau, c’est pas une faille de sécurité, c’est un abîme.



 





Euh, non, ce n’est pas du tout, du tout, du tout, ce que j’ai dit, lire, pas extrapoler, merci…



Bon, puisqu’on a dévié jusqu’ici, je vous fais la version longue pour essayer de recentrer le débat (qui pour rappel était : async/await est plus utile dans du code qui interroge un serveur que dans du code qui répond à un client)



J’ai juste dit que chacun des modules fonctionnels expose un port (généralement un micro-serveur http) qui permet à n’importe quel client de se connecter, (1) sans SSL (2) ni mot de passe, pour obtenir un heartbeat et les paramètres essentiels de fonctionnement du module (p. ex. si le module est un frigo, sa température).



Ceci permet à tous les noeuds du système de périodiquement vérifier que les autres noeuds qu’il connaît sont en état de fonctionnement optimal, et lancer localement des alertes si nécessaire.  Cette architecture hautement redondante est indispensable pour détecter rapidement les services qui ont cessé de fonctionner, surtout et y compris quand c’est précisément un module centralisé qui s’est vautré. Cette architecture n’utilise pas la technologie “push” pour exactement les mêmes raisons.



Passer exclusivement par un serveur centralisé est une couche supplémentaire inutile et compliquée ; elle est surtout dangereuse car ajoute un single point of failure.  Demander un chiffrement SSL occupe des ressouces processeur qui seraient mieux exploitées par le module à faire autre chose, tout en n’offrant aucune réelle protection. Pareil pour un mot de passe. Le seul risque réel pouvant être une attaque DOS sur le serveur web d’un module, ce serveur est expressément limité quant aux ressources qu’il peut occuper.  D’où, notamment, pas de SSL, aucune vérification de MdP, aucun parsing des arguments, rien : j’ouvre le socket, je ne lis pas ce que le client a envoyé, j’écris mon status précédé d’un header http minimaliste et je ferme le socket ; en gros, comme le démon quotd sauf qu’on n’envoie pas un sonnet de Shakesepeare.

 

Cette architecture permet accessoirement d’écrie une “simple” page html & js qui interroge quelques modules bien choisis et affiche leurs paramètres de fonctionnement. Ce qui était là où je voulais en venir depuis le début.

 

Le 13/07/2016 à 14h 09

brazomyna a écrit :



Ça dépend beaucoup du contexte et des contraintes qu’il impose en effet. 



Quant au mono/multi-thread, faut arrêter de dire n’importe quoi: on peut parfaitement faire des applications multithreadées avec node, on trouve les explications en moins de 30 secondes dans la doc de node (cf child-process)





Le contexte : accumuler des données en provenance d’équipements connectés sur le réseau dont quasiment aucun ne supporte ssl et qui négocient le mot de passe (quand il y en a un, bien sûr) en clair…



Pour le reste, Paraplegix me dit que c’est monothread… mettez-vous d’accord entre spécialistes.

Le 13/07/2016 à 10h 49

Ah de fait, j’ai rien compris à ce que tu dis, en effet… Une application industrielle en tout JavaScript tournant sur un serveur Node/JS (dont j’ai appris récemment qu’il était monothread) juste pour “passer pour un pro” ? " /> 



Moi je te parle juste d’un tableau de bord qui collecte les indicateurs de performance du système depuis les différents équipements, calcule les corrélations, qu’on peut afficher sur n’importe quel PC, tablette, téléphone ou écran au mur..



Je ne vois vraiment pas l’intérêt concret de faire ça autrement que directement en JS dans une page html unique, servie statiquement par l’intranet du site.



Le coeur de métier est évidemment en C / C++ / Delphi dans des serveurs d’applications dignes de ce nom et sécurisés. En multithread. Avec des attentes de réponse synchrones et sans callbacks… 

Le 13/07/2016 à 05h 56

vloz a écrit :



Mais dans cette situation autant directement faire une app nodejs… ¯\_(ツ)_/¯





Bah oui, allons-y, ajoutons une couche intermédiaire tournant sur un noeud qu’il faudra provisionner, qui peut tomber en panne, sur lequel il faudra installer les patchs de sécurité, qu’il faudra maintenir, dont il faudra convaincre la DSI d’ouvrir les bons ports du firewall…



Ca va vachement augmenter la stabilité de l’application, tout ça. " />

Le 12/07/2016 à 17h 29

vloz a écrit :



Normalement ce genre de comparaison tu les fait coté serveur, pour etre sur de ce qui est envoyé au client, le foutre en cache, l’analysé, etc… ca evite d’enfeindre la Same-origin policy et c’est au final surtout une question de bon sens…





C’est surtout une question d’architecture. Et de contraintes. Et de mode. Tu pars naturellement du principe que l’application est hostée sur un serveur et déployée sur Internet, en grande partie parce que c’est à la mode.



Les applications du monde industriel, et en particulier celles que nous développons dans ma boîte, ne s’appuient pas toutes sur ces principes. Notamment, la solution que j’emploie, destinée à un réseau local, n’a pas besoin de serveur centralisé, tous les traitements se font en local sur le client.

Le 12/07/2016 à 16h 44

Paraplegix a écrit :



Dans NodeJS, pour faire court, la réponse c’est Non. Nodejs est monothread.

 





Ah ouais, dans ce cas évidemment… Comme dit précédemment, je n’utilise pas Node.JS pour de “vraies” applis. Quand je dois embarquer un serveur, je suis un dinosaure moi, je fais ça à la main en Delphi avec Indy." />



Bon, ben merci à tous de m’avoir remis sur la bonne voie.

Le 12/07/2016 à 16h 14

Ha oui, on est bien d’accord que faire de l’aynchrone c’est pratique partout.  Je dis juste que le “syntactic sugar” apporté par la notation async/await ne permet pas de simplifier le code d’un serveur autant qu’il permet de simplifier le code d’un client, c’est tout… 



 

vloz a écrit :



   

 Ca coté client, c’est moche… 





Pourquoi c’est moche ? Si j’ai besoin de demander une offre à deux sites de réservation d’hôtel, puis d’afficher la plus intéressante, je suis bien obligé de faire les deux requêtes et comparer les résultats une fois que je les ai obtenus tous les deux. Le plus efficace c’est de faire les deux en même temps, je vais quand-même pas attendre que le Formule 1 réponde avant de lancer la requête vers le Hilton… Et c’est précisément quand on veut faire ce genre de choses que les notations async/await sont les plus intéressantes.

Le 12/07/2016 à 15h 25

CryoGen a écrit :



Et si ta fonction f() mets 10 minutes à compléter et donc “retourner” (" />) tu fais comment ?





Ben… On est bien en train de parler d’un serveur, non ? La fonction f() est invoquée dans un thread ; donc le serveur continue à servir les autres clients dans d’autres threads, non ? Et si f() prend 10 minutes, ben, il faut bien que j’attende qu’elle ait fini avant de répondre au client, non ?

Le 12/07/2016 à 14h 59

J’suis pas trop convaincu que les callbacks NodeJS soient adaptés à une utilisation avec async/await, justement…



Je n’utilise pas beaucoup Node.JS (hou le doux euphémisme), mais quand je déclare un callback, c’est souvent un pattern :



      “crée un serveur http, et chaque fois qu’un client demande la ressouce /f.html/, appelle la fonction f()”.



 C’est cette notion de “chaque fois que” qui ne me semble pas compatible avec await/async, qui est plutôt “attends une seule fois qu’une action produise son effet, puis continue au statement suivant”.





 



 

Le 12/07/2016 à 12h 51

Heu j’ai un peu de mal à piger ton point de vue. Async / Await ça a au contraire plus de sens sur le client que sur le serveur, piske ça sert justement à attendre que le serveur réponde sans devoir créer une fonction de callback :



    x = AsyncGetResource1 ();

    y = AsyncMakeQuery2 ();

    MyElement.InnerText = await x + await y;

Le 12/07/2016 à 07h 15

lldlf a écrit :



Si les sources de Dalvik sont disponibles, alors il suffit de faire un code compare et tout le monde sera fixé  ;°)





Selon mes souvenirs, ce n’est pas Dalvik qui est en cause (il est, forcément, complètement différent puisqu’il se base sur une architecture VM complètement opposée) mais la librairie de classes standard.

Le 10/07/2016 à 11h 35

Bah oui, j’ai pas grand chose à ajouter, c’est juste. Je m’offre néanmoins l’occasion d’étaler ma culture sur le sujet.



L’OS maintient l’heure “locale” pour l’affichage à l’utilisateur. Cette heure peut varier par à-coups tant en avant qu’en arrière pour diverses raisons (passage heure d’hiver / heure d’été, déplacement dans un autre fuseau horaire, p. ex.)



On peut éliminer une partie de ces problèmes en utilisant l’heure UTC qui n’est pas censée être ainsi décalée, mais on court toujours le risque que l’heure maintenue par le PC se désynchronise de l’heure UTC réelle. Cette horloge n’est donc, elle non plus, pas immunisée contre les variations abruptes, qui se produiront quand l’utilisateur (ou le démon NTP…) “remettra les pendules à l’heure”.



Une application qui veut conserver l’ordre temporel des événements indépendemment de ces possibles variations doit donc utiliser une base d’horloge qui garantit a minima que le temps ne recule jamais, et si possible de ne jamais bondir vers l’avant non plus. Sous Windows on utilise GetTickCount, sous Unix il existe une CLOCK_MONOTONIC qui fait essentiellement la même chose. Cette horloge a le désavantage qu’elle est totalement indépendante du temps légal (p. es. GetTickCount donne le nombre de millisecondes depuis le démarrage du PC, il revient donc parfois à zéro, mais jamais au cours d’une exécution du programme), et il faut conserver les deux temps : le temps “tick” pour trier / comparer en interne, mais le temps légal pour afficher.



Enfin et pour finir, un programme qui “reconstruit” l’heure en calculant 3600heure + 60minute + seconde aura du mal avec une seconde intercalaire, alors qu’un programme qui demande à l’OS de lui fournir une valeur prédigérée (nombre de secondes écoulées depuis un moment précis dans le temps) n’aura pas ce souci (tant que l’OS fait lui aussi correctement son boulot, évidemment)

Le 08/07/2016 à 16h 16

AmaCha a écrit :



Le problème se pose surtout pour les applis “temps réels”.

Mais aussi logs, et éventuellement base de données, systèmes de fichiers, …



Enfin que des trucs pas sensibles du tout en fait… " /> " />





Ouais, heuh, le mec qui développe une appli temps réel en se basant sur l’heure légale qu’il obtient en décodant depuis la représentation string HH:MM:SS au lieu d’utiliser les “ticks” système (qui eux sont garantis monotones) … comment dire … ben … c’est un peu bien fait pour sa tronche si ça se plante.

Le 08/07/2016 à 17h 32

Ouais enfin le but est d’apporter la connectivité là où il n’y en a pas, tout en permettant aux gens du coin d’utiliser l’existant. Donc 2G parce que tous les téléphones le supportent. Si c’est pour développer un téléphone qui travaille dans la bande wifi et les obliger à en acheter un, c’est pas la peine, autant leur dire d’utiliser un téléphone satellite…

Le 06/07/2016 à 07h 05

Zappi a écrit :



Comment vous faites pour vous faire tirer portable, porte feuille, pc ?

Vol à la tire je peux comprendre, ont ne peut casi rien faire mais se faire piquer son porte feuille ou téléphone dans la poche j’ai du mal à comprendre.





 Je me suis longtemps posé la question moi aussi.

 Et puis un jour, en sortant du métro (de Rome …), j’ai compris.

 Et pourtant j’avais fait attention.

 Cette leçon vaut bien un portefeuille, sans doute.

Le 04/07/2016 à 14h 22

Commentaire_supprime a écrit :



J’ai cru comprendre que, du moins pour ses débuts, Itanium était très en retard et qu’il était difficile de coder pour cette architecture. Si quelqu’un qui s’y connaît pouvait compléter mon propos, il serait le bienvenu.





Si je me rappelle bien ce qu’a dit Raymond Chen, l’Itanium ne tente pas lui-même de garantir l’ordonnancement optimal des instructions, c’est le compilateur qui doit le faire.



 En gros, le processeur exécute les instructions exactement dans l’ordre où on lui dit de le faire, et c’est le compilateur qui doit s’arranger pour que si une instruction écrit son résultat p. ex dans R1, elle soit suivie par des instructions qui n’ont pas besoin tout de suite de R1 sous peine de devoir attendre. Ca économise les transistors car le processeur ne doit pas réordonnancer les instructions à la volée, mais si le compilateur ne fait pas parfaitement  le boulot, les performances sont catastrophiques.



Le compilo doit donc savoir combien de temps prend chaque instruction pour les séquencer correctement.

Le 01/07/2016 à 05h 17

>> la grande question est de savoir comment il compte faire pour atteindre 650 millions d’appareils supplémentaires au cours des 24 prochains mois









 En proposant un prix attractif pour la migration depuis Vista / XP " />

Le 24/06/2016 à 14h 17

+1024 " />

Le 24/06/2016 à 14h 16

Séphi a écrit :



Tu n’as surtout pas l’air d’avoir compris le principe d’Insider.

Ici, on parle d’un OS en bêta avec inscription pour y participer, tu n’es pas obligé d’être sur le W10 bêta, tu peux très bien être sur celui de Prod et là les builds ne s’enchainent pas. " />





Je pense qu’il a bien compris. Il se plaint juste (mais faut relire depuis son premier post, et pas juste réagir au dernier) que la version de production a un bug dans le client Remote Desktop, et que ce bug n’est corrigé que dans les versons bêta de l’insider. Il a donc le choix entre une insider qui se met à jour trois fois par semaine, ou une prod stable qui ne lui permet pas de travailler.



D’un autre côté, j’utilise MSTSC en W10 prod vers des machines W7 sans rencontrer les ennuis qu’il décrit, donc bon, ça a l’air subtil comme bug…

 

Le 24/06/2016 à 14h 08

vampire7 a écrit :



Petite analogie :

Tu payes ton médecin pour un service. Peut-il faire ce qu’il veut avec ton corps ?





Bah oui, poussons l’analogie, elle est très bonne. Un médecin peut t’interdire certains comportements qui mettent ta santé en péril, par la force s’il le juge nécessaire (en psychiatrie notamment) ou plus simplement en refusant de te prescrire certains médicaments. Il n’a pas le droit pour autant de te tuer délibérément.



 De la même manière, Windows t’interdit du mieux qu’il peut de faire certaines choses qui pourraient nuire à l’intégrité du système, et il a parfaitement le droit de le faire (sinon, tu peux aussi revenir à Windows 95 qui ne t’interdisait pas d’écrire n’importe où en mémoire - c’est TA machine après tout… et poutant, dans ce cas précis de protection mémoire, tout le monde est ravi que la protection est active et non désactivable)



 Mais il n’a pas le droit de flinguer délibérément la bécane…

 

Le 16/06/2016 à 10h 03

Soriatane a écrit :



On connait quelles technolgies ils vont utiliser pour leur lecteur vidéo?? Espérons que cela sera en HTML5, car proposer que du Flash alors même Safari et Edge demande une activation pour le lancer….





Silverlight ou une applet Java " />

Le 15/06/2016 à 13h 53

gvaudan a écrit :



Mais :

De même, le stockage “dans le cloud” est aussi un stockage physique. Déporté, fractionne éventuellement, et même dispersé, mais toujours physique.non ? 





Si 1000 personnes enregistrent le même épisode de Zorro sur France 3, Molotov TV ne doit pas nécessairement avoir 1000 copies “physiques” dans le cloud, une seule suffit (hormis évidemment les réplications pour backup et load balancing)

 

Le 15/06/2016 à 10h 11

et le 7 618e comportait les adresses des 7 167 précédents destinataires. 



 Ca fait quand-même 450 adresses email qui n’ont pas été divulguées… " />



 Bon, évidemment le gag de CommitStrip tombe mal : http://www.commitstrip.com/fr/2016/06/13/the-end-of-an-expensive-era/Edit : le lien passe pas :  &nbsphttp://www.commitstrip.com/fr/2016/06/13/the-end-of-an-expensive-era/



 

Le 13/06/2016 à 13h 59

hollaamic a écrit :



Je vois vraiment pas ce que MS peut avoir comme avantages dans ce rachat. 





Vu le nombre de gens qu’ils sont en train de licencier, ça coûte moins cher de leur filer un compte Linked In gratos que de faire un plan emploi…" />

 

Le 31/05/2016 à 17h 44

FunnyD a écrit :



, du mireille mathieu à fonds dans la sono.  





Mireille Mathieu, c’est en Chine qu’elle allait chanter " />



Et en Chine, les droits de l’homme, c’est pas tout-à-fait ça. Donc oui, il y a corrélation : Mireille Mathieu c’est bien un traitement inhumain.

Le 31/05/2016 à 13h 29

FunnyD a écrit :



Evidemment, tu fais du compost. " />

Tu construits les prisons dans le désert sans clim, ça en dissuaderait plus d’un. " /> Éventuellement, tu prévois un truc pour qu’il ne puisse pas s’échapper, j’sais pas, du genre un boulet au pied, ça serait déja un bon début.





C’est un peu comme ça qu’ils font les prisons au Mexique. Ca ne donne pas l’impression que ça dissuade les cartels…

Le 18/05/2016 à 10h 58

TiTan91 a écrit :



Donc Google décide unilatéralement que ces 10 sites sont sûrs, et que le reste c’est le deep web dangereux pour votre pc…

Aucun souci de discrimination, non……" />





Oui, tout comme Google peut choisir à quels certificats root il fait confiance…

Le 18/05/2016 à 07h 21

Dyonisos84 a écrit :



C’est pas’discriminatoire’ ce comportement ? Soit on arrête partout soit nul part…





Je suppose qu’ils ont fait une analyse de risques, et autorisé uniquement les sites qui ne proposent que des contenus flash non-vérolés. Le problème n’est pas le plug-in en lui-même dans son coin, le problème c’est que certains contenus vérolés exploitent des failles pour injecter du code. Si le processus de streaming de Youtube garantit en amont que les contenus sont “légaux” (au sens du format de fichier, pas des droits d’auteur) les risques sont nuls.

 

 

Le 13/05/2016 à 13h 02

psn00ps a écrit :



Fais l’essai sur comctl32.dll et prends 3 fichiers identiques.

tu verras qu’il compte plusieurs fois la taille.





Pffff. De fait :-(

Le 12/05/2016 à 17h 59

psn00ps a écrit :



" /> Voilà. Quand c’est fait correctement, la bonne taille est affichée. C’est bien par l’inode.

 





Bah oui, LS les compte en double et DU (qui veut dire “disk usage” accessoirement) les compte une fois.



Donc exactement comme l’explorateur de Windows, qui ne les compte qu’une fois dans “space used on disk”…

Le 12/05/2016 à 12h 09

Ce n’est pas un bug de l’explorateur, c’est le fonctionnement normal des hard links. 

 

Quand on utilise des hard links, il n’y a pas un des liens qui est l’original et les autres des références indirectes vers l’original (ça, ce sont des symlinks), les deux liens sont exactement égaux en tout point et aucun des deux n’a de statut privilégié : si j’ai deux hardlinks, je peux supprimer n’importe lequel des deux, l’autre continuera à “pointer” vers le fichier. C’est évidemment fait exprès pour que si je détruis par erreur un fichier dans c:\windows, la copie dans c:\winSxS est toujours valide, et vice-versa.



Pour être plus clair, le but de WinSxS est de servir de backup pour les fichiers système de Windows, l’utilisateur voit donc deux répertoires totalement indépendants, un qui est le répertoire système, l’autre qui en est le backup. Il s’attend donc logiquement d’une part que leur tailles soient grosso modo identiques, et surtout que la destruction accidentelle d’un fichier système n’entraîne pas immédiatement sa disparition dans le backup, sinon ça ne sert à rien.



Il se fait simplement que NTFS applique une sorte de “compression” en ne conservant sur disque qu’une seule copie avec deux noms différents, mais cela ne gomme pas le fait que, stricto sensu, ce sont deux fichiers à la durée de vie totalement séparée.

 

Le comportement des hard links est d’ailleurs identique dans les FS Linux sans que personne n’appelle ça un bug ; voici un lien qui en parle :



http://unix.stackexchange.com/questions/88423/why-do-hard-links-seem-to-take-the…

 

 C’est pas pour rien que l’appel système Ux pour “détruire” un fichier s’appelle unlink() et pas delete().

Le 12/05/2016 à 10h 31

Ce n’est pas un bug de l’explorateur. La taille rapportée est la somme des tailles des fichiers de l’arborescence, indépendemment de la place qu’ils prennent sur le disque (qui est rapportée correctement). Exactement comme quand il y a des fichiers compressés.



Ce n’est pas nécessairement intuitif, mais pas plus que faire l’inverse : imagine que l’explorateur dise que WinSxS n’occupe “que” 64K en tout. J’en copie le contenu sur une disquette (de 720K …) et l’explorateur me dit “désolé, y a pas la place”…

 

Le 12/05/2016 à 09h 10

WinSxS ne contient que des “hard link” vers les vrais fichiers. Le fichier n’est stocké qu’une fois sur disque, mais sa taille est comptée deux fois (une fois dans son emplacement normal, l’autre dans WinSxS)

Le 06/05/2016 à 14h 24

Oui et attention les gars ! Dans les ascenseurs, il y a aussi de la télémétrie. Chez Otis ils savent à quelle heure vous rentrez, avec qui, si vous étiez tous les deux du même côte de la cabine, et au bout de combien de temps elle est redescendue. Ils peuvent bloquer l’ascenseur juste assez longtemps pour qu’elle se retrouve nez-à-nez avec votre femme qui vient de rentrer. Et ils savent quand vous avez pris du poids… Et en plus le logiciel est propriétaire et fermé et la copropriété doit financer les entretiens.



En gros, exactement la même chose que ce que vous reprochez à Windows ; mais bien sûr, vous ne prenez pas l’escalier… Ca vous ferait plus de bien que Linux, pourtant.



On peut dire la même chose des voitures, des trains, des avions. Vous avez toujours une bonne raison de les utiliser malgré qu’ils ne sont pas “ouverts” alors arrêtez de vous prendre pour des cadors simplement parce que vous vous êtes “libérés de l’infâme Microsoft”.

 

Le 02/05/2016 à 11h 25

Ho comme je suis… il est écrit “moins gourmande” et moi je crois comprendre “moins gourmande … en mémoire”. Ouffff me voilà rassuré je ne vais pas devoir me prendre la tête pour revendre la moitié de mes barrettes ram sur eBay…

 

Le 02/05/2016 à 11h 17

MS s’était déjà lancé dans un truc similaire, mais local : Mayhem. La sauce n’avait pas pris et le bazar a été swordé. Tu m’étonnes, tiens … comme ils avaient fait ça “à la Microsoft”, Mayhem n’acceptait que du .Net 2.0 et Powershell du .Net 4.0 donc pas moyen d’avoir une librairie de fonctions à partager entre les deux plateformes, fallait les DLL en double… Pas encore de portable libraries à l’époque.



 Comme il me reste encore quelques classes C# que j’avais écrites à l’époque pour jouer avec la bête l’espoir renaît, avec un peu de chance, on pourra les injecter.

 

Le 29/04/2016 à 10h 56

Drepanocytose a écrit :



Pas dit que le dev passe quand même du temps à chiader son code ; ca lui facilite de le faire, mais pas sûr qu’il le fasse.

Ils y a les bons devs et les mauvais devs, c’est comme les chasseurs " />





Certes, mais c’est surtout la contraposée qui s’applique : un bon programmeur face à un compilo qui met des plombes en aura vite marre de perdre son temps " /> et fera ses modifs à la pelle à neige plutôt qu’au scalpel micrométrique.

Le 29/04/2016 à 09h 06

Drepanocytose a écrit :



Voilà. Gros +1.

Aujourd’hui faut faire du code vite, très vite. OSEF que le soft soit pourri dans le fond et codé avec les pieds, tant qu’il est design et qu’il sort vite





Bah non, justement. Au plus le compilo est rapide, au plus il y a de chances que le développeur passe du temps à écrire du code correct au lieu de jouer au solitaire en attendant que son binaire arrive. Des cycles de compilation courts favorisent les micro-améliorations incrémentales, les tests automatisés, etc…



Perso quand j’ai commencé à programmer il fallait soumettre la compilation en batch et attendre 15 minutes dans la file (j’ai eu de la chance, l’année d’avant c’était encore des cartes perforées) et honnêtement ça ne me manque pas. " />

Le 26/04/2016 à 16h 22

Voilà bien l’archétype du cafouillazibule mal ficelé que je ne comprendrai jamais… Les fichiers sur volumes NTFS peuvent déjà être signalés comme “non présents physiquement” (= archivés sur stockage tertiaire) et malgré ça Microsoft arrive avec une solution bancale dans son propre produit OneDrive… Y sont forts, y’a pas à dire.

Le 26/04/2016 à 10h 49

H2O a écrit :



Si quelqu’un trouve un logiciel très utile pour cette taille d’écran, 





Afficher l’heure " />



La seule application que je vois ce serait un GPS piéton, avec une grande flèche qui dit par où aller

Le 25/04/2016 à 11h 18

Burn2 a écrit :



ça dépend comment on récupère la machine, si c’est un truc qu’on connait pas, en général on évite de le brancher sur son réseau sans isolation etc. " />



Surtout un vieux tromblon qui est peut-être un vivier. :o



Enfin après c’est peut-être mon côté parano qui me dit ça. " />





Moi pas faux non plus… " />Mais bon, un vieux 98 en face d’un Linux récent, y’a peut de chances qu’il fasse du dégât … aussi vérolé qu’il soit, je le vois mal dégainer un zero day genre heartbleed & co.



Même chose dans l’autre sens, le plus petit malware actuel ne tient pas  dans un PC de l’époque, imagine la news : un gars qui réussit à écrire un malware qui fait une élévation de privilèges sur Windows 98, il est doué ! 

Le 25/04/2016 à 10h 36

Burn2 a écrit :



Donc compliqué pour récupérer quoi que ce soit sur internet. " />





Y’a pas que le HTML dans la vie hein… Un Windows 95 (voire un 3.11) ça a un client FTP, un accès aux fichiers partagés sur le réseau. Au pire l’application Terminal et ZModem en telnet. 



 " />



 

Le 23/04/2016 à 10h 24

127.0.0.1 a écrit :



Et ca ne serait pas plus simple de développer directement des technologies pour la médecine, l’automobile ou l’énergie ? Faut essayer d’atteindre la Lune pour inventer l’airbag ??





Il est peut-être bon de rappeler que ce qu’on envoie dans l’espace, c’est pas des liasses de billets de banque, hein. En réalité, le “coût” de l’opération c’est en grande partie utilisé à payer des gens pour leur travail, du plus prestigieux scientifique au plus obscur (et pourtant taut aussi indispensable, soi dit en passant) balayeur ou gardien de nuit.

Le 19/04/2016 à 08h 53

Sqlutsqvq a écrit :



Ah les français et leur manie de voir le mal partout…





Raté, une fois :-)

Le 19/04/2016 à 08h 30

Cool. En captant la différence de pression sur l’écran, le constructeur pourra désormais refuser la garantie d’un téléphone tombé dans l’eau, en pouvant opposer au client les informations de pression : quelle partie, pendant combien de temps, dans quelle position et à quelle profondeur il est resté immergé. " />



Apple est très intéressé par la technologie.



Sinon, pour en revenir à la nouvelle, de fait, le “long press” a depuis longtemps été associé à un “alternate click” / “bouton droit”… pour y faire apparaître un menu contextuel. Et c’est plus simple à gérer qu’une différence de pression je trouve.



Bon, à la réflexion si l’écran distingue l’effleurement de la pression franche, la règle 34 s’applique, non ?

Le 18/04/2016 à 10h 49

MaiEolia a écrit :



Euh c’était déjà possible de ne pas synchronisé. Je le fais depuis des mois …





Oui, manifestement il est aussi possible de ne pas lire l’article avant de commenter. Certains le font depuis des mois." />

Le 15/04/2016 à 11h 20

Dyblast a écrit :



Et ça sera possible quand de pouvoir compiler un simple programme C/C++ avec Visual Studio sans avoir besoin de 12 Go de disque dur? Alors que bon, une toolchain doit tourner dans les 500 Mo ainsi que 500 Mo IDE … on est loin des 12 Go.





https://blogs.msdn.microsoft.com/vcblog/2015/11/02/announcing-visual-c-build-too…



(Peut-être grillé par Firefly…)

Le 08/04/2016 à 13h 03

Laurius a écrit :



Ce n’est pas à toi de démontrer que tu ne savais pas que c’était illégal, mais au parquet de démontrer que tu savais que tu savais ce qu’il y avait derrière le lien.

tale ou Google, l’exemple est fallacieux, il n’y a pas d’élément intentionnel dans ce cas.





Et donc en pratique c’est inapplicable car il sera impossible à un humain de vérifier au cas par cas quand, comment et pourquoi un lien vers une page illégale est présent ; donc ça va être délégué à des cabinets d’avocats payés à la pièce qui vont lancer des bots parcourir le Web et faire chr tout le monde avec des requêtes cease-and-desist à tort et à travers…