Le 18/11/2019 à 11h 30

“hack” (bidouillage) est un terme très répandu en programmation également, ça ne se limite pas à aller s’infiltrer dans les serveurs privés. Du coup ça me choque pas.

Le 18/11/2019 à 11h 25

L’invention de nouveaux mots était peut-être débile, mais ici ce n’est ni plus ni moins que des traductions, bref je ne vois pas en quoi il s’agit d’un enrichissement de la langue. Finalement c’est juste une sorte de dictionnaire du jargon , sans rien toucher à la langue. Je ne vois pas bien l’utilité à ce qu’un organe public fasse ce travail.

Le 14/11/2019 à 23h 04

Dans ma boite on bosse énormément en télétravail, et dans l’ensemble ça se passe très bien pour les employés comme pour la boîte.



C’est sûr que culturellement c’est un gros changement de passer au

télétravail, qui implique sûrement une sensation de perte de contrôle de la part

du management. Mais ça peut être remplacé par une autre forme de relation avec les employés, avec des rapports peut-être plus formels et plus réguliers, il ne faut pas croire que les managers  sont totalement démunis pour s’assurer qu’il n’y a pas d’abus. 



Ça peut être des discussions 1-1 avec les employés, et/ou des rapports écrits réguliers du travail effectué par chacun, et puis si vraiment il y a de gros doutes sur quelqu’un, souvent le travail fourni est vérifiable. Et petit à petit, quand ça devient intégré dans la culture de l’entreprise, les managers finiront par se détendre :-)



Et puis aussi, si quelqu’un fait 2 heures de console sans rien dire, finalement si le travail est bien fait à côté, est-ce que c’est réellement un problème? Le télétravail comprend aussi une part de réappropriation de son temps et de son rythme de travail.

Le 13/11/2019 à 16h 09

Uther a écrit :



L’annonce

originale explique longuement les intérêt de la démarche. Le principal

est de fournir une isolation entre les différent des composants de

l’application, un peu comme des containers en beaucoup plus léger.  Cela

permettrait de réduire les risque de faille de sécurité par import de

module depuis un dépot de style npm vu que chaque module aurait une

restriction des droit qui lui sont accordé (accès au fichiers, aux

réseaux, à la mémoire …)





D’accord, je ne connaissais pas cet aspect.  Mais là encore ça me paraît plus indiqué pour palier aux déficiences de l’écosystème JS que des languages backend (sauf node.js du coup). Même si en théorie une lib malicieuse dans n’importe quel language peut faire des dégâts, allez savoir pourquoi, j’ai l’impression que c’est surtout dans l’écosystème JS qu’on voit ces problèmes, non? Je me rappelle encore de celle-ci:https://snyk.io/blog/malicious-code-found-in-npm-package-event-stream/ qui avait fait pas mal parler.



 





brice.wernet a écrit :



D’ailleurs, la doc est auto-traduite, ce qui rend blazor “éblouissant” doc du serveur éblouissant (me rappelant une démo Azure dont on pouvait automatiser la config grâce à “coquillage puissant” " /> )





 " />

Le 13/11/2019 à 12h 02

J’avoue que le WebAssembly en backend j’ai encore du mal à voir l’intérêt (l’argument “une seule runtime partout” ne me paraît pas très intéressant) , par contre dans le navigateur oui ; donc je le vois plus volontiers en concurrence avec le runtime JS (qui est pété dans tous les sens). Par contre si Apple/Google/Microsoft ne suivent pas, ça risque d’être un gros problème.



Et les languages comme TypeScript qui “transpilent” en JS pourront très bien également “transpiler” en wasm d’ailleurs il y a déjà un certains nombre de projets sur les rails pour ça. Cfhttps://docs.assemblyscript.org/ par exemple.

Le 14/10/2019 à 13h 04

Même pas drôle, un article Linky et aucun complotiste anti-onde dans les commentaires… :-(

On veut des #NousSachons

Le 02/10/2019 à 15h 32

J’aime beaucoup mieux cette version, bravo!

Le 02/10/2019 à 09h 17

Pas que twitter :https://downdetector.fr/



J’aimerais pouvoir accéder àhttps://hub.docker.com (peut plus bosser…) " />

Le 24/09/2019 à 16h 07

Angelblue a écrit :



Pour Qwant, il sont déjà français et ils ont plutôt bien détaillé leur fonctionnement avec Microsoft. Donc bien que je suis pas à l’aise avec cela, je comprends qu’il faut du temps pour faire sont propre index.





Il y a deux choses différentes à ne pas mélanger : les recherches qui peuvent passer par Microsoft Bing le temps en effet que Qwant améliore sa techno d’indexation ; et d’autre part l’utilisation de Microsoft Azure pour déployer l’infrastructure. Ce second point avait été critiqué par certains et défendu par Nitot d’autre part (perso j’avais trouvé les explications de Nitot convaincantes) ; mais en tout cas il n’est pas prévu (de ce que j’ai pu lire) que Qwant se passe de Microsoft pour la partie infra (azure).

Le 23/09/2019 à 17h 23

C’est intéressant et je suis persuadé que ça joue un rôle énorme pour “percer” dans un business en effet.



 Faut juste savoir s’arrêter et se mettre en retrait au moment opportun.

Le 23/09/2019 à 09h 28

js2082 a écrit :

• le message corse: tout le monde a ri (jaune), “tout le monde a compris, le message est passé” = dans le sud, cette expression signifie que tu as compris les menaces qui pèsent sur toi et que le message “tu vas crever si tu parles” a été compris. Je ne sais si M. Champeau joue à l’imbécile ou se moque de nous là,
  
   
  
  
  
  
  
  Sur l’histoire corse ce que j’en comprends après la réponse de Champeau c’est surtout qu’on manque de contexte et que c’est monté en épingle de façon pas tout à fait honnête. Je n’ai pas du tout compris qu’il s’agirait d’allusions pour menacer les salariés eux-mêmes.
  
   
  
   
  
  
  
  
  
  js2082 a écrit :
  
  
  


• sa vision du journalisme est très particulière “voilà que l’histoire qui devrait au contraire le servir est racontée de travers, déformée, amplifiée, dans le but de nuire, par une source qui a des comptes à rendre”: en clair, le journalisme doit être à ses pieds et tous ceux qui disent le contraire doivent rendre des comptes… Drôle de concept du journalisme.  
  
  
  
  
  
   
  
  
  
  Non, ce passage concerne les volants / rampants & la moustiquaire… Champeau contredit le témoignage en disant qu’au contraire Léandri s’était fermement opposé à ces vannes & à ce vocabulaire. C’est parole contre parole pour nous, impossible de savoir qui dit vrai, mais c’est pas du tout une remise en cause du journalisme, en tout cas pas comme ça que je le vois. Quand il parle de la source qui a des comptes à rendre, c’est pas du journaliste qu’il parle mais de l’ex-salarié.
  
  
  
  
  
  Après, je trouve que Champeau répond à deux ou trois petits points mais c’est une broutille devant l’ensemble du problème soulevé.

Le 21/09/2019 à 20h 47

Il faut espérer que les investisseurs fassent pression pour exiger une meilleure gouvernance. Leandri doit se mettre en retrait, s’il est intelligent il le fera de lui-même sinon espérons qu’il y soit contraint.

Le 19/09/2019 à 16h 09

Mithrill a écrit :



Je pense surtout qu’au fil des années les gens pensent que Mr Nitot n’est qu’un opportuniste qui a du bagout, un très bon communicant mais à l’éthique plus que limite du genre faites ce que je dis mais pas ce que je fais…





Pourquoi à l’éthique plus que limite? J’ai dû rater des épisodes…

Le 16/08/2019 à 21h 32

Pourquoi incohérente? On parle de SF hein … on n’a pas dit qu’il serait posé par des humains :-)

Le 15/08/2019 à 07h 24

Pas con le coup du miroir, je suis sûr que ça pourrait faire partie d’un bon scenar de SF

Le 10/08/2019 à 09h 31

+1

J’ajoute qu’en tant qu’utilisateur régulier de qwant, plaçant de l’espoir en ce moteur de recherche, mais pestant aussi régulièrement devant des résultats souvent moins pertinents que ceux de google : oui cet article m’intéresse et m’interpelle, notamment les passages parlant de la dispersion des efforts au détriment du moteur de recherche principal.



Donc merci JMM et Next Inpact

Le 08/08/2019 à 21h 49

Alors, oui il s’agit de problèmes internes à Qwant, et non on ne les trouve pas dans toutes les start-ups – idée qui ferait croire que c’est une fatalité. Ce ne sont certainement pas des problèmes qu’il faut minimiser ou relativiser (“toutes les startups font ça” …). Je trouve normal que les salariés fassent entendre leur voix, et prévisible - quand la pression monte trop - que certains se rebiffent. C’est juste logique.



J’imagine bien que les dirigeants de Qwant ne sont pas ravis que ces documents aient été rendu public, mais aujourd’hui s’ils veulent panser leurs plaies c’est aux problèmes remontés dans ce cahier de doléances qu’il faut s’atteler. Au cas où on se soit mal compris, c’était le sens de mon message précédent.

Le 08/08/2019 à 17h 30

Ce qui m’attriste dans ce genre d’histoire c’est que tout le monde se focalise sur “qui est à l’origine de la fuite” / “pourquoi ça paraît dans la presse” ; ici mais aussi certainement chez Qwant en interne , ce qui à coup sûr débouchera sur une chasse à l’homme, sans forcément résoudre le fond des problèmes.

Le 08/08/2019 à 15h 19

Et ben… c’est la loi des séries pour Qwant en ce moment, ça me fait de la peine pour eux, mais d’un autre côté ça va peut-être aussi créer les secousses dont ils ont besoin au niveau du management ?



J’ai aussi vécu ce genre de choses dans le passé et (ouf!) aujourd’hui j’en suis loin! J’enfonce sans doute des portes ouvertes, mais pour avoir vécu le bon et le mauvais, il me semble que le management est vraiment au cœur de ce genre de problème. Il faut oublier le command & control ; confiance doit être le maître mot - et ce même lorsqu’on pense que certains abusent et ne sont pas assez productifs - lorsqu’on créée plein de règles pour lutter contre les abus, toujours garder en tête que les “bons” (les plus productifs, les plus créatifs…) en pâtiront tout autant. En fait si y’a plus de confiance, c’est que la partie est perdue.



L’agilité, et scrum en particulier, il faut le voir avec un regard critique. Une startup qui crée son produit a la chance de pouvoir s’affranchir d’un fléau des projets contractuels : les deadlines. Quand je lis “on a tenu les deadlines” ça me hérisse le poil pour une boîte comme Qwant. Pourquoi vous vous emmerdez avec ça? Vous êtes vraiment tenus par les c pour ne pas imposer votre cadence? Et si c’est vraiment le cas, est-ce vraiment sérieux de se disperser autant sur des produits secondaires? Ce qui compte c’est de construire quelque chose robuste et pérenne, ou bien de satisfaire ce genre d’objectif court-terme? À un moment il faut arrêter de se disperser et prendre le temps de bien faire les choses, laisser du temps aux développeurs de peaufiner, d’expérimenter, de réfléchir.



Un exemple - je sais pas si ils bossent en sprints ; dans mon équipe on fait des sprints en mode léger : déjà, pas de story-point (donc pas de temps perdu en évaluations futiles, de culpabilisation lorsqu’on prend + de temps pour mieux faire les choses, etc.) ; mais alors, comment on remplit le sprint si on n’a pas cette métrique? C’est simple, on ne le remplit pas vraiment. Enfin si, quelques grands sujets prioritaires quand même (oui ça existe), mais sans forcing ; à tout casser ça prend 50% du temps. Et chaque développeur ajoute un peu ce qu’il veut, prend le temps de traiter les problèmes selon son propre ressenti, etc.. Pour le bien-être du produit et de l’humain. Et au final ça marche.

Le 26/07/2019 à 11h 11

Oui et j’ajoute que personne n’est infaillible, même les meilleurs développeurs peuvent avoir un coup de mou un jour et se planter. Si les langages peuvent aider à plus de sécurité, c’est à prendre, surtout dans le cas de rust où ce n’est pas compromettant pour les perfs.



D’autant que ce n’est pas ici juste une lubie de hipster, ça part d’un constat très concret (et négatif) sur les correctifs de sécurité, donc ce n’est ni plus ni moins que du pragmatisme.



Pour avoir essayé rust, c’est un langage très rigoureux à la compilation … ce qui peut donner quelques crises d’arrachage de cheveux à l’écriture, mais la récompense est toujours au bout du chemin, comme dit l’article, quand ça compile, ça marche.

Le 30/06/2019 à 08h 50

TheKillerOfComputer a écrit :



Les volumes ne sont que des sortes de liens symboliques, et il faut que ça ait été prévu à l’avance. Le container en soi reste immutable, on ne touche pas au contenu en linkant un fichier Apache.conf extérieur par exemple.





Dans le cas où Valve réutiliserait une techno de containers immutables (ce qui n’est pas évident IMHO), la question, notamment pour les moddeurs, sera de savoir où sera la délimitation entre la partie mutable et la partie immutable (comme je disais, il y aura forcément une partie mutable, ne serait-ce que pour les settings du jeu). On peut imaginer que ce seront les développeurs des jeux qui feront ce choix, selon le degré d’ouverture du jeu, justement pour les mods. Finalement ça ne change pas grand chose à l’état actuel des choses : on trouve déjà des développeurs qui veulent compliquer au maximum la rétro-ingénierie (comme tu le disais plus haut) et d’autres qui sont plus ouverts, qui souhaitent “stimuler” la communauté.



Mais encore une fois, j’ai pas l’impression que Valve en ait quelque chose à carrer de l’immutabilité. Ce qui les intéresse c’est plus le gestion des dépendances, il me semble… Du coup ils pourraient très bien partir sur une techno / implémentation moins contraignante pour les moddeurs tout en gardant l’aspect “layers” pour les dépendances.

 

Le 30/06/2019 à 08h 30

Oui, et de plus, il ne faut pas réduire le rôle de Canonical à du packaging. Parmi la pléthore de libs, ils doivent bien en maintenir eux-même une certaine partie, il ne font pas que se reposer sur le travail des autres.

Le 29/06/2019 à 13h 56

Saymonz a écrit :



Mais du coup c’est quoi la surcharge de travail à sortir une librairie ou une application en 32bits en plus du 64bits ? Je pensais naïvement qu’il “suffisait” de le dire au compilateur  et de corriger les éventuels bugs spécifiques (ce qui doit être plus ou moins complexe en fonction de quoi on parle bien sûr) ?



 

Le build en lui-même est une toute petite partie de l’équation, en effet builder le 32bits en plus du 64bits n’est pas ce qui va poser beaucoup de soucis. En revanche, en terme de tests et de support, c’est une autre histoire. On multiplie la surface à couvrir, je ne sais pas si le coût a été chiffré, mais c’est certain qu’il y en a un.

 

On peut voir aussi l’aspect sécurité, c’est d’ailleurs évoqué dans ce thread qui date de l’année dernièrehttps://lists.ubuntu.com/archives/ubuntu-devel/2018-May/040310.html : “Machines running i386 Ubuntu which are capable of running amd64

Ubuntu are vulnerable to the critical Meltdown vulnerability where they

wouldn’t be if they were running amd64.”



 

Le 28/06/2019 à 20h 43

J’ajoute aussi que les containers ne sont pas totalement read-only. Sinon, comment on gèrerait les sauvegardes ou la config? Avec les technos de type docker, on peut créer des volumes pour gérer ces choses-là (et donc exposer/partager des fichiers sur le host)



Mais même, est-ce vraiment à ça que valve pense quand ils parlent de containers? Est-ce qu’ils ne partiraient pas sur leur propre techno, ou un dérivé? J’ai pas l’impression que l’aspect “immutable” soit ce qui les intéresse.

Le 27/06/2019 à 17h 35

Sauf que valve ou wine n’ont certainement pas envie de gérer eux-mêmes le support de toutes ces dépendances, c’est pas vraiment leur job et c’est énormément de boulot.

Le 27/06/2019 à 17h 21

Juste pour précision parce que l’article est un peu ambigu : on peut dors et déjà utiliser steam sur d’autres distros qu’ubuntu. Perso je l’ai sur fedora.

Le 17/06/2019 à 18h 29

Sinon, y’a des développeurs impliqués qui prennent le relai de l’éducation nationale défaillante : Twitter

Le 22/05/2019 à 20h 38

Un exemple de domaine qui est assez peu optimisé aujourd’hui : les scripts pour les outils de continuous integration (travis, jenkins, circle ci …) bien souvent on télécharge la terre entière en dépendances maven ou nodejs à chaque build, alors qu’elles pourraient être mises en cache. Comme c’est du build et pas du runtime, on s’en fout un peu, c’est pas critique.



Builds qui vont bien souvent péter pour un test unitaire à la con qui passe pas, qu’on va relancer 3 fois parce que “c’est la faute à pas de chance” … bref oui ce genre de comportement je le vois souvent (et je jette pas la pierre ça m’arrive parfois) mais il faudrait être sensibilisé au coût environnemental pour prendre la peine d’optimiser le CI/CD.

Le 22/05/2019 à 08h 02

Oui, d’autant qu’avoir leur propre infra c’était justement leur modèle jusqu’à maintenant, donc on ne peut pas leur reprocher de ne pas avoir essayé, sauf qu’à un moment ils ont dû faire le constat que ça devenait trop compliqué à gérer, que ça n’allait pas scaler, que s’ils veulent améliorer leurs capacités il faut changer de modèle.



 Bien sûr dans l’absolu c’est possible de suivre la même voie que Google, mais ça demande des investissements faramineux que personne n’est en mesure d’apporter. Y’a qu’à voir les fiascos des tentatives de “cloud souverain”.

Le 21/05/2019 à 11h 15

PS pour OVH, j’ai juste cherché 2 secondes (sur Qwant " />) :https://www.vpsbenchmarks.com/compare/azure_vs_ovh



Je sais pas ce qu’il vaut ce benchmark, mais par exemple sur la latence, il semble qu’OVH et Azure ne jouent pas dans la même cour. Bon, à prendre avec des pincettes ce genre de benchmark, comme toujours.

Le 21/05/2019 à 11h 09

Il faut être cohérent avec ses idées mais il faut aussi parfois ravaler sa fierté quand on voit qu’on n’y arrivera pas. C’est tout l’art du compromis et ça leur fait sûrement pas plaisir d’en arriver là (je suis sûr qu’en interne ça a dû batailler dur aussi!).



Mais comme le dit Nitot, on parle d’indexation ici, donc sans rapport avec la partie “privacy” qui reste le cœur du sujet pour Qwant, de ce point de vue là il n’y a aucune compromission.

Le 21/05/2019 à 10h 56

M’enfin ! a écrit :



Genre il n’y avait pas moyen de travailler avec des acteurs européens ou français ? Genre ???





Je crois que la réponse est claire : Non. Pas pour leurs ambitions, en tout cas. Il faut voir les choses en face : si le problème n°1 de Qwant c’est la pertinence des résultats (et il me semble en effet que c’est là où ils doivent s’améliorer), ils ont besoin de décupler leur puissance d’indexation. Et pour ça les offres les moins coûteuses aujourd’hui elles se trouvent de l’autre côté de l’Atlantique. À un moment, il faut être un peu pragmatique, c’est soit ça, soit rester sur un modèle qui ne scale pas et donc stagner.



Perso j’utilise Qwant mais je switche souvent sur Google car les résultats ne me conviennent pas. Je veux bien croire qu’ils prennent la bonne direction avec une infra d’un gros provider cloud.

Le 20/05/2019 à 21h 07

Furanku a écrit :



…

Même si personnellement j’ai décidé de ne plus passer par eux pour mes recherches :)





Si je peux me permettre, pourquoi? Tu dis toi-même que d’un point de vue technique ça se comprend… Donc s’ils veulent grandir, Qwant est condamné à faire ce genre de choix. Ou doivent-ils se résoudre à rester éternellement un tout petit acteur?

Le 20/05/2019 à 20h 59

J’ai bien compris que le débat ici se lit sous un angle “éthique”, mais pour ma part je trouve ça plutôt cool qu’ils aient choisi Azure. En face y’a quoi … Google ou Amazon? Sont-ils plus vertueux? Sachant que l’approche “on fait tout à la maison” finit par montrer ses limites.



Après j’imagine que d’un point de vue technique pour leurs besoins, les 3 se valent, ils supportent sans souci kubernetes. C’est certainement une affaire de gros sous.

Le 21/05/2019 à 15h 53

bast73 a écrit :



 

J’aurais plutôt dit l’inverse … Le vert c’est la couleur à laquelle on est le moins sensible.







Si si, il me semble bien aussi que l’oeil est plus sensible au vert (dans le sens où c’est dans les tons de vert qu’il distingue mieux les nuances).



 Pour la petite histoire, c’est pour ça qu’à l’époque des jeux codés en RGB 16bits, il y avait 6 bits pour le vert et 5 pour le rouge et le bleu.

Le 21/05/2019 à 11h 40

Cumbalero a écrit :



Imaginer éliminer la lumière bleue avec une appli, la solution de ceux qui commentent sans avoir lu.

Se fier à son ressenti, quelle bonne blague.

Ce n’est pas parce que vous faites cracher du jaune à votre écran que ça va éliminer le bleu, ce n’est pas un filtre.





Ben… si justement. Si tu réduis le bleu à 0, t’as du jaune. C’est controlable en software, ou via les réglages de ton écran. C’est juste … moche.

Le 14/05/2019 à 14h 15

Pareil … Mais ça reste des recommandations assez vagues, pour la plupart. Ça ne ressemble pas beaucoup à un document sensé faire référence.

Le 02/05/2019 à 19h 24

On voit mieux sur le site de l’annonce, ça tire plus vers le rose :https://www.redhat.com/en/blog/announcing-next-evolution-our-red-fedora-mark?sc_…

Le 02/05/2019 à 19h 15

J’ai fait l’upgrade 29 -> 30, ça tourne comme un charme. Nickel " />

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 :-(