Reprise du message précédent :
Est ce que ton correspond à sa messagerie hébergée chez gmail ?
 
Tu envoies des mails depuis orange ? un exchange ?

Je suis chez Free et j'envoi mes courriels via un client de messagerie sur mon PC (Livemail).

L'entreprise de mon correspondant a un nom de domaine et un serveur en interne qui reçoit les courriels.

Est ce que le destinataire ne ferait pas une redirection des mails arrivant sur son serveur interne vers gmail ?
 
Le message d'erreur fait penser à du gmail.

Normalement non puisque c'est leur serveur d'entreprise. Mais je poserai la question.

 
Leur informaticien me dit qu'ils ont bien cette adresse de secours chez Gmail.
 
Mais il ne comprend pas du tout pourquoi j'ai ce retour avec justement cette adresse de citer.
 
Il lance un scan de virus sur son serveur.  

qu'est ce que dit un nslookup sur leur mx ?
ca serait pas leur seconde porte d'entrée  le gmail ?
et que le mx1 est hs.

Il peut pas mater les logs ou ajouter de la verbosité pour connaître le déroulement du truc ?

si c'est du domino c'est chiant à rajouter

Domino ?

pff ces linuxien.

Salut,
Vous utilisez des adaptateurs ethernet wi-fi pour connecter des périphériques qui n'ont qu'une interface ethernet ?
 
Un truc transparent, sans drivers, qui se configure et se plug en RJ45 pour raccorder un matériel sur un réseau wi-fi.
 
J'ai l'impression que ce n'est plus trop courant ce genre d'accessoire.
rien chez ubiquiti, on trouve des pont réseau tp-link ou Asus.
 
Merci
Jet
 

un répéteur Wifi avec une prise RJ ?

Wut ? Un AP quoi

+1

 
Quand j'avais du faire ça, j'avais mis du AirGateway d'UBNT. C'est juste un peu chiant de devoir se trimballer l'injecteur.

Ca, il n'y a que lui qui le sait.

C'est leur adresse de secours m'a-t-il dit.

Bah, pourquoi reçoivent-ils tout de même le courriel ?

Je ne vais pas aller expliquer à l'informaticien son métier.      

Encore faut-il que ça en soit un

Heu, wi.    
 
Le coup de l'anti-virus sur le serveur, j'ai acquiescé par politesse, mais bon…    

On a un problème de lenteur avec un serveur et une appli métier.
L'éditeur qui nous répond qu'ils ont changé les prérequis, mettez votre serveur conforme aux prérequis et revenez nous voir.
Mais depuis quand on change les prérequis en cours d'utilisation ?
 
En plus l'appli qui stocke les documents scannés et fichiers dans un seul dossier.
Il y a un dossier avec 280.000 fichiers, rien que l'ouverture du dossier met un temps fou.
Mais comment les dev peuvent avoir cet idée géniale de tout mettre dans le même dossier ?
C'est pourtant pas compliqué au moins de faire des sous dossiers.

Quand on ne sait pas coder...

il y aussi eu un formateur de cette société venu donner une formation.
Et il se plaint au client que l'application est lente et qu'ils devraient aller voir leur presta info pour réparer ces lenteurs.
 
Mais c'est leur VM, on n'est pas censé y toucher et si on fait la moindre merde dessus,  
ils vont se retourner contre nous pour nous dire que c'est de notre faute et qu'on avait pas à y toucher.

La réponse moyenne de l’éditeur moyen...

 
Faites du SaaS, ça sera encore moins casse couille

C'est les preco de l'accès au net qui va changer.
J'ai même eu droit a l'explication du client tse qui était trop lent.
 
La mauvaise fois est un truc sans fin.

"Quand on ne donne pas les moyens aux devs de devs correctement" surtout

C'est clairement pas la majorité des cas hein.
De ce que j'ai vécu, c'est tout simplement mauvais. C'est à peine si les gens comprennent ce qu'ils codent.
Encore que ceux qui font du TDD se posent au moins des questions (et encore c'est possible de faire des assertions bullshit..)
J'en ai vu, ils ne savaient même pas comment marchait un PC..

 
 
T'as pas forcément besoin de savoir comment fonctionne un moteur pour utiliser une voiture .
 
Suivant ce que tu dev t'as pas forcément besoin de connaître comment fonctionne un PC ;p .

T'as quand même besoin de comprendre que c'est le volant qui fait tourner ta voiture, les roues qui la font rouler, les freins freiner, etc..

Même principe. Si un moment tu sais pas à quoi sert ta RAM dans le PC, désolé mais t'as déjà loupé une grosse partie des bases sur le développement..

"Donner les moyens" c'est aussi les formations, c'est aussi faire des code review, c'est aussi imposer des standards, se faire suivre par des seniors/lead/archi, etc etc... C'est accepter d'avoir du temps d'optimisation, de faire des benchs, etc.
 
Mais vu que tout ça coûte cher, bah le management va te dire qu'on a pas le temps, pas les moyens, etc et qu'il suffira d'acheter plus de ram
 
Ca n'excuse pas les mauvais mais quand t'es un profil pour qui c'est juste un taff et que les seuls choses qu'on te demande c'est de finir vite, bah tu finis vite en réduisant au max les bug mais l'opti/conso/etc ça n'a même pas le temps de rentrer dans ton scope de travail quoi

C'est sûr que si tu rencontres un dev qui ne sait pas à quoi sert la RAM dans un PC, y'a ptet eu une erreur de recrutement
Enfin n'importe quelle personne technique dans l'informatique

 
Mauvaise comparaison.
 
autant t'as pas besoin de savoir comment marche un [moteur/pc] pr t'en servir,
autant il me parait plus judicieux de savoir comment ça fonctionne quand tu dois faire [une voiture /un software] qui va s'en servir.
 
mais visiblement, ça ne parait pas evident pr tt le monde.

Ce qui drôle aussi c'est quand t'es dans une équipe qui administre des middlewares, que tu te retrouve coincé entre d'un côté une infra pourrie car on a tiré sur les budgets d'achats de machines et d'un autre côté des devs miteux fait par des prestas avec un max de turnover...
Bien sûr quand c'est lent les utilisateurs se plaignent... et c'est forcément la faute de ton middleware qui n'est pas bien optimisé.

Chez nous on nous a reproché que l'infra était pourri.
J'ai du le faire une thèse d'analyse avec tous les graphes des outils de monitoring pour leur montrer que l'infra se touchait les boules et qu'elle était surdimensionnée parce que l'on a toujours compensé la mauvaise qualité du produit par des rustines.

24h pour sortir 100 lignes d' export de données (et 7Go de mémoire bouffé pour une DB de 20Go durant l'export), ça choquait personne.. A part un seul con en production qui disait qu'à un moment va falloir se sortir les doigts du cul.

Mais bon tellement plus facile de rajouter du vcpu, de la ram, du disque que de faire les choses bien.
Mais dans le long terme y a tout qui s'écroule.

Et avec le cloud publique c'est encore pire, vu que tout est dispo tout de suite, y a juste à payer.
Aucune capitalisation et rationalisation.

Quick 'n dirty.

Tu as justement un lien direct entre la qualité de ce que tu produits et la facture. C'est plus facile de montrer le coût direct du mauvais dev et le ROI du bon dev.

Chez nous l'infra est vraiment pourrie, avec des équipements réseau qui datent du début des années 2000 et des hyperviseurs archi sur-provisionnés en Ram, CPU et même espace disque.
Bien évidemment la hiérarchie voit aussi dans le cloud un échappatoire à tous ces problèmes, en plus c'est "gratuit" (enfin c'est pas les mêmes budgets) et facilement scalable en allongeant la monnaie.
Puis c'est le cloud c'est fashion surtout.

 
ben oui. Ca n'a généralement à peu près aucun intérêt pour un développeur de connaître le fonctionnement/gestion de la RAM par le CPU et l'OS de la plateforme sur laquelle il développe. Il n'y a probablement pas 10% du topic qui sait ce qu'est une faute de page ou l'impact de la fragmentation des données en mémoire
 
A mon avis, tout ce dont un développeur a besoin de savoir concernant la RAM, ça se résume à pas grand-chose:
- c'est une ressource en quantité limitée (on évite d'en consommer inutilement)
- l'accès est beaucoup plus rapide qu'un disque

On a ça aussi avec les clients qui mettent plein de CPU sur une VM pour qu’elle « rame pas » et dans esxtop on voit des valeurs de %ready qui crèvent les plafonds    
 
Après une petite sensibilisation à NUMA en supplément, les VM sont vite dégraissées

 
Tiens ca me rappelle notre erp qui rame a toc.
 
J'ai demandé a l'editeur si on peut pas elager un peu parce que 90Go de db ca me parait monstre (on a 10 users hein).
 
Réponse : achetez des disques c'est pas cher.
 
Oui mais ces 90Go me font chier a chaque manip, certaines requêtes font exploser les logs, la sauvegarde est pénible, bref je suis pas dbadmin mais 90Go pour quelques milliers de client et autant de refs de produit ça cadre pas.
 
2ans après cet épisode, leur dev/sav viens chez nous : oui c'est lent c'est votre machine, faudrait une machine dimensionnée ( J'ai un DL380 G9 avec 64Go de ram 2 proc et 3 grapes raid1 (sysy, db et log) pour ça )
Après avoir regardé le serveur : a oui ça devrait tourner mieux...
Après qu'il ai tricoté je ne sais quoi pendant ma semaine de congé la base est passé a 40Go, un script de maintenance régulier est apparu ( en virant mes scripts de sauvegarde au passage   ).
 
Et au final ça plante moins mais ça rame toujours...
   
 
 

on a le syndrome aussi chez nous, t'as un lien pour faire de la stat (hv/esx) histoire que je puisse avoir des billes ?

Ah tiens, j'ai le même discours consumériste au sein de ma formation où j'ai fait une remarque pour optimiser le temps de traitement et réduire la conso mémoire : "Oui on peut faire comme ça aussi mais on va pas se faire chier comme dans les 80's, on a plein de ressources dispo maintenant".

 
si tu as de la doc/lien explicative(f) sur Numa, ça m'interesse.