Le 02/05/2019 à 19h 12

Dès que le rachat par IBM est validé, ils rajoutent la cravate bleue

Le 09/01/2019 à 12h 02

fcthulhu a écrit :

L’informatique ou le numérique au sens large, ce ne sont pas des baguettes magiques qui font pousser la logique, tout au plus il y a un côté ludique et interactif plus présent que dans d’autres matières, mais la logique en elle même, on l’attrape tout autant en jouant aux legos.


Disons que, la pratique de la programmation va quand même entraîner le cerveau à une certaine forme de logique. Mais c’est ça qui est important : une certaine forme. Le cerveau s’adapte aux problèmes auxquels on est confronté et il n’y a pas qu’une seule et unique forme de logique, c’est peut-être là où le raisonnement du type pèche.
La programmation a ce côté empirique qui la rend sans doute plus accessible que des matières plus théoriques mais, à mon avis, la discipline reine pour la logique ça reste les maths et par ailleurs le fait que nos ministres veulent les supprimer du tronc commun au lycée… ça ne va vraiment, vraiment pas dans le bon sens.

Le 07/01/2019 à 17h 56

Pourquoi un stage? Bah, peut-être simplement parce que la DGSE doit compter son fric comme tous les organismes publics et qu’ils espèrent que l’attrait du “jeu vidéo” suffira à attirer du monde?

Le 07/01/2019 à 17h 48

C’est pas qu’on ne peut pas faire de l’asynchrone, mais c’est juste … plus chiant. En Javascript l’écosystème s’est largement développé autour de ça, avec les “promises”, des objets maintenant intégrés au langage qui sont dédiés à la gestion de résultats asynchrones (je ne sais pas si C++ a un équivalent, peut-être, mais encore faut-il que les API utilisées en tirent partie).
Et contrairement à un modèle multi-threadé qui favorise les race conditions (donc : risque de bugs accru, maintenance & debug plus difficile, “lourdeur” du code pour y palier…), le mono-thread javascript est beaucoup plus simple.

Après pourquoi Javascript? J’imagine qu’il y a des raisons politico-historiques liées à Mozilla, Thunderbird réutilise le moteur gecko de Firefox qui donc interprète le javascript, ceci expliquant peut-être cela. Je suppose que ce n’est pas utilisé dans toutes les couches du logiciel, mais uniquement dans la partie visuelle? (ça semblerait logique à vue de nez)

Le 07/01/2019 à 14h 22

Juste un mot à propos de Javascript… je suis d’accord avec toi, à première vue ça paraît aberrant de passer de C++ à Javascript pour gagner en perfs. À noter qu’ils ne parlent pas là de passer toutes l’appli en JS, mais juste le traitement des filtres. J’imagine que l’appli est déjà hybride C++ et JS.

En fait, c’est pas tellement le langage qui compte ici, mais le fait qu’il veulent passer de C++ synchrone vers JS asynchrone. Le fait est que C++ n’est pas un langage de choix pour faire de l’asynchrone, alors que JS se développe autour de ça depuis des années (avec son event loop pour palier au défaut du mono-thread). Bref les perfs ne viendront pas du langage mais de la façon dont il est utilisé.

Le 30/10/2018 à 18h 02

Bah, les goûts et les couleurs…
Perso j’aime bien, je suis sous XFCE du coup j’hésite à réessayer gnome.

Le 30/10/2018 à 16h 55

Ben alors NextInpact, vous avez massacré leur logo?

Le 30/10/2018 à 17h 30

Si j’ai suivi tu as bossé chez IBM. Pour tout dire, je suis chez Red Hat et je suis forcément un peu inquiet de la forme que prendra l’intégration sur le moyen / long terme mais loin d’être abattu pour autant. Comme c’est dit dans le lien posté au-dessus, ça risque d’être un choc des cultures (culture managériale notamment). Les déclarations d’intention, pour le moment, sont rassurantes. Pour les employés de Red Hat, ce n’est pas le moment de fuir (même si j’imagine bien qu’il y aura quelques départs), mais plutôt le moment d’affirmer cette culture et de montrer qu’elle fonctionne.

Sur le plan technique, IBM est tellement vaste que ça me paraît difficile de généraliser. J’imagine bien qu’ils se traînent tout un paquet d’applications “legacy” peu reluisantes - (il y en a aussi chez Red Hat - d’ailleurs paradoxalement ça peut très bien être des succès commerciaux). Je sais aussi qu’ils ont des équipes brillantes avec un sacré niveau d’expertise, ils ont leurs research labs, il y a déjà beaucoup de collaboration entre Red Hat et IBM, ce côté là sera renforcé.

Le 30/10/2018 à 15h 26

http://markclittle.blogspot.com/2018/10/red-hat-and-ibm-really.html

“suggesting that IBM will kill or stifle the Red Hat culture […] it’s unlikely because no company has ever acquired a company quite like
Red Hat before. Our culture of openness is incredibly strong […] I’m pretty confident to say that it won’t
happen because we won’t let it happen.”

Le 29/10/2018 à 22h 01

SebGF a écrit :

Dans tous les cas, IBM n’aurait aucun intérêt de torpiller les projets communautaires de Red Hat vu combien ces produits sont utilisés en entreprise que ce soit dans leur version gratuite ou payante. D’autant plus que le communiqué de presse va en ce sens.



Je me fais beaucoup moins de soucis pour CentOS, qui est quelque part un dérivé de RHEL, que pour Fedora. Bien sûr c’est un projet communautaire qui pourra continuer à vivre de lui-même, mais IBM continuera-t-il d’y allouer des ressources ? Contrairement à RHEL et par effet de bord CentOS qui ont une vraie étiquette “business”, Fedora n’est pas hyper courant en entreprise.

Quant au communiqué de presse… Rien d’étonnant à ce qu’il se veuille rassurant. Ça n’engage que ceux qui veulent y croire.

Le 29/10/2018 à 16h 33

Nioniotte a écrit :

Et que deviendra Fedora ?


J’ai pas l’impression que Big Blue ait grand chose à faire de Fedora :-(

Le 27/06/2018 à 11h 57

Zerdligham a écrit :

Ce que tu décris est un manque de perfectionnement de la librairie de parsing plus qu’un défaut du langage lui-même. Des librairies plus performantes existent.
Sinon si tu valides pas tes inputs avant de les traiter, il y a un problème à chercher ailleurs que dans le langage utilisé " />
 


Ah, alors comment le parseur pourrait deviner les informations de type? Je ne vois pas comment ce serait possible puisqu’elles disparaissent au runtime. On est obligé de se refrapper un second typage custom propre au parseur (comme avec la lib que j’ai citée plus haut, type-check), qui vient s’ajouter aux types définis en typescript. C’est juste lourdingue à utiliser. (Mais s’il existe d’autres solutions je serais heureux de l’apprendre)

Tandis que dans d’autres langages le parser connaît le type (par exemple en java, on fournit un .class concerné, en go il se débrouille avec juste la référence de l’objet)
 


Zerdligham a écrit :

Je ne suis pas trop d’accord. Si tu mets du any partout c’est par facilité, le langage offre tous les outils pour ne pas avoir à le faire.
Rien ne t’empêche de faire toi-même quelques définitions, ou de caster proprement les résultats ‘garantis’ de la lib, comme on cast les résultats void* de tout un tas de fonctions C génériques (pas toujours explicitement d’ailleurs).


Ben ça c’est dans un cas merveilleux où les devs javascript d’une lib donnée ne mettent pas tout et n’importe quoi dans un objet. Va définir un type pour un objet complètement polymorphe, qui peut recevoir des valeurs, ou pas, dans 30 champs différents, où un champ donné peut représenter tour à tour un nombre, une string, une fonction… C’est pas impossible mais tu te retrouves  avec tellement d’optionnels et d’union types que tu ne seras certainement pas avancé à la fin. Je pense par exemple à “d3”, lib bien connue des amateurs de graphes. Même dans les tests des définitions de types c’est bourré de “any” :https://github.com/DefinitelyTyped/DefinitelyTyped/blob/master/types/d3/v3/d3-te… .

Sans compter qu’à la moindre mise à jour d’une lib qu’on aurait typé soit-même il faut de nouveau tout revérifier.
 

Le 26/06/2018 à 16h 52

Je suis d’accord tu peux faire des cast dégueulasses en C, mais ce genre
de choses se voit dans le code. Le comportement par défaut est safe, si
tu veux être unsafe tu dois le rendre explicite => pour moi c’est la
bonne façon d’appréhender les choses.

 Typescript règle une
bonne partie des problèmes du javascript mais malheureusement pas tout. Un exemple simple: tu récupères du JSON d’un appel HTTP. Ce json va être désérialisé avec quelque chose du genre JSON.parse . Là, avec typescript tu définis le type de l’objet reçu. Tu n’as aucune garantie à la compilation que le json matche le type indiqué. Si ça pète ce sera au runtime. Tu me diras, c’est exactement pareil avec n’importe quel langage quand on parse du texte. Sauf qu’avec un autre langage, c’est à la déserialisation que ça va échouer, donc immédiatement (donc “fail fast”) tandis qu’avec typescript, le compilo a beau avoir les informations de typage, au runtime (JS) il n’y en a plus aucune donc JS/TS ne peut pas reporter d’erreur rapidement, ce qui fait que l’erreur risque de se propager bien plus loin dans les appels et sera potentiellement beaucoup plus difficile à détecter. (il y a des libs qui existent pour ce genre de chose, comme “typecheck” si mes souvenirs sont bons, mais assez relou à utiliser).

Ça peut paraître lointain ce genre de préoccupation mais perso je l’ai vue et revue cette situation.

Sinon y’a aussi le fait que pour s’interfacer avec bon nombre de libs JS il faut encore utiliser du “any” à tout bout de champ (donc l’intérêt de typescript s’envole).

Le 26/06/2018 à 16h 20

Ben oui, je trouve que typescript est un super langage, sa plus grande faiblesse c’est qu’au runtime ça reste du javascript donc toutes les erreurs de typages peuvent “leaker” malgré tout.

Le 26/06/2018 à 16h 15

th3squal a écrit :

Ce n’est plus le petit langage de scripting pour apprendre sur une page web, c’est un langage qui actuellement possède beaucoup d’atouts vis à vis d’autres langages plus évolués (Class, Prototyping, Closures, etc)


/troll on
Le jour où il y aura du typage statique et que les erreurs ne te pèteront plus à la figure au runtime on pourra dire que c’est un langage sérieux :-)

Le 08/01/2018 à 22h 49

Ils disent aussi:
 “Because microbenchmarks like netperf/uperf, iozone, and fio are designed
to stress a specific hardware component or operation, their results are
not generally representative of customer workload. Some microbenchmarks
have shown a larger performance impact, related to the specific area
they stress.”
 
Ou encore:
  “If an application is running on a system that has consumed the full
capacity of memory and CPU, the overhead of this fix may overload a
system payload, resulting in more significant performance degradation.”

 Bref, ces tests ne correspondent pas exactement à des cas d’utilisation concrets.
A priori, les PC personnels n’ont pas grand chose à craindre (mais nous verrons bien), ce sont plutôt les solutions d’entreprises (cloud/virtualisation/etc) qui pourraient souffrir. A noter qu’un provider cloud a intérêt à utiliser au maximum les capacités de ses machines pour les rentabiliser. C’est là où ça peut faire mal.

Le 11/12/2017 à 09h 48

Sauf que si tu veux faire tourner les algos de machine learning pour améliorer la prédiction, tu vas pas le faire sur le petit snapdragon de ton smartphone. Je ne sais pas si ai.type fait du machine learning, mais ce ne serait pas déconnant.

Le 06/12/2017 à 13h 04

Non mais faut pas exagérer, mettre un mot de passe sur une base mongo (on parle pas de chiffrer le contenu hein, on parle juste de mettre un mot de passe) c’est pas ça qui coûte de l’argent, n’importe qui peut le faire en 2 minutes. Il n’y a aucun intérêt à ne pas le faire, vraiment j’en vois aucun, ou alors faudra m’expliquer plus en détail. A part l’ignorance, je vois pas.

Le 06/12/2017 à 12h 20

Va savoir… J’ai trouvé ça un peu gros aussi comme gaffe, au premier abord… puis je suis allé voir leur linked-in qui recense 12 employés, on peut deviner plus de la moitié en marketing, bref, ça n’a pas l’air d’être si pointu techniquement. Surtout du bla-bla. Je parierais plutôt sur de l’amateurisme :-)

Le 06/12/2017 à 12h 13

Bah non c’est sans doute pas intentionnel, en tout cas je vois pas l’intérêt. Ils peuvent même pas revendre les données puisqu’elles sont librement accessibles. C’est juste de l’amateurisme.

Le 06/12/2017 à 10h 40

anagrys a écrit :

 

En tout cas elles ne sortent pas de chez Apple (ou Google pour Android).
Ou pas…? " />


Difficile à dire, mais au moins elles ne se retrouveront pas sur un serveur MongoDB librement accessible sans authentification ni chiffrement!

Le 06/12/2017 à 08h 45

FlamingFlowair a écrit :

Hmm, en même temps, la présence des contacts dans les prédictions du clavier sont utiles bien que pas indispensable.


Exact. De même, l’enregistrement des séquences de mots sera utilisée pour les prédictions futures.
Reste que ça donne aux claviers virtuels un rôle ultra sensible qui nécessite une attention toute particulière de google/apple.

Le 06/12/2017 à 08h 21

Quoi de mieux qu’un clavier virtuel pour faire un keylogger? " />

Les apps permettant de remplacer le clavier virtuel devraient
systématiquement être auditées par google/apple avant d’atterrir sur les
stores.

Le 08/12/2017 à 11h 20

ra-mon a écrit :

Si ça se trouve, ils demandent aussi à Google, en contrepartie de l’intégration rémunératrice en tant que moteur de recherche par défaut, de scrupuleusement respecter la vie privée, au moins des utilisateurs de Firefox qui cherchent par défaut chez eux " />


C’est beau de rêver  " />
Mais je crois que dans ce domaine, Google n’est prêt à aucun compromis.

Le 07/12/2017 à 08h 04

Ce que tu dis vaut aussi pour les champs avec auto-completion, je vois mal comment on pourrait faire le distingo entre les deux, dans les deux cas on transmet au serveur des données non validées. Ce n’est pas la technique en elle même qui est répréhensible, mais sa finalité.

Le 06/12/2017 à 15h 09

NaviStone ne fait pas de l’auto-completion , elle fait du ciblage comportemental. Donc il y a fort à parier qu’en effet, elle collecte un maximum d’informations pouvant traduire les centres d’intérêts des utilisateurs.

Le 10/01/2017 à 16h 46

Ceci dit il y a fort à parier que parmi les bases piratées, il y a un bon pourcentage de déchets, des bases abandonnées ou utilisées pour des choses tout à fait secondaires, qui expliqueraient un tel laxisme.

Le 10/01/2017 à 16h 42

CryoGen a écrit :

Non mais là c’est pas le problème, il s’agit d’un problème de config, aucune mise à jour ne peut régler çà simplement en général. A moins d’y aller à coup de diff ou autre, ca ne peut être fait en automatique… on parle de solution pro tout de même.


Non seulement ça, mais en plus pour sécuriser il va bien falloir mettre un mot de passe, ou configurer quelque chose… je vois pas comment ne pas passer par la case “config”.

Le 20/08/2015 à 14h 39

“En clair, l’éditeur espère faire de Go la plateforme de développement à
tout faire, réduisant pour les développeurs le besoin de recouvrir à un
trop grand nombre de langages différents. Un créneau déjà assez
concurrentiel, avec notamment Xamarin pour faire le lien vers
l’environnement .NET.”
 
Je dirais qu’au contraire, en faisant des ponts vers C/C++ Google encourage la fragmentation: il s’adresse aux développeurs qui maintiennent une appli legacy C/C++ et qui souhaitent évoluer en douceur vers un langage plus moderne sans devoir tout réécrire en one-shot.

Le 20/08/2015 à 14h 27

Si on devait comparer Go à un autre langage ce serait plutôt Rust: des langages proches de C/C++, orientés performances (quoique encore en deçà de C/C++) mais également orientés déploiement (une des “philosophies” de Go étant le packaging monolithique, l’appli Go contient en elle-même toutes ses dépendances, pas de library externe). Il en résulte moins de soucis de dépendances, mais des livrables plus encombrants.
 

Par contre ce qui est moche dans Go, c’est que tous les concepts modernes passent à la trappe, en ce qui concerne la programmation fonctionnelle. Tout ce que peuvent apporter des langages comme Scala / Haskell / Java 8 (streams) etc. De ce point de vue, Go est très “old school”.

Le 10/09/2014 à 08h 47

Leynas a écrit :

facepalm

Pour arriver à faire un raccourci pareil faut vraiment… non, je ne vois même pas comment on peut y arriver en fait.

Leynas.



Raccourci? Quel raccourci? Je dis simplement que je ne vois pas comment on peut légiférer de façon globale sur les “algorithmes prédictifs”, c’est un terme qui englobe beaucoup plus de choses que ce qui est visé politiquement. Ce sont les domaines d’application qui doivent être ciblés, pas les “algorithmes”, ça ne voudrait rien dire.

Le 10/09/2014 à 07h 17

Hem.. est-ce que le conseil d’état sait ce que signifie “algorithme”? La définition est très large, n’importe quel programme informatique contient des algorithmes qui vont effectuer des choix sans intervention humaine, c’est même la base de l’informatique…. le Conseil d’Etat voudrait lutter contre l’informatique?

Le 27/08/2014 à 17h 30

Jed08 a écrit :

En quoi avoir deux modes de jeux différents totalement indépendant est mauvais pour le jeux ?



Vu le passif de la boîte, y’a de quoi être inquiet quant à la qualité du mode solo. Alors si en plus y’a des signaux négatifs envoyés sur le multi, on peut présager du pire…