💼Vague de licenciement dans la tech ? | Actus DevOps Juin 2023

cchaudier · Juin 29, 2023, 8:36

Quelles sont les dernières nouveautés dans le monde du cloud et du DevOps en ce mois de Juin ?

Comme à notre habitude nous voilà de retour avec l’Actus DevOps mensuel, pour t’aider dans ta veille.

Aujourd’hui, je suis avec @Uggla et @Erwan on parle de :
Dégraissage dans la tech
Des processeurs plus simples
La typo qui a cassé Azure au Brésil
Un panorama des outils Cloud

N’hésites pas à réagir à ces nouvelles et à donner ton point de vue en commentaire.

Article de blog : https://lydra.fr/vague-de-licenciement-dans-la-tech-actus-devops-juin-2023

Rejoins la communauté des Compagnons du DevOps (c’est gratuit je précise) : https://www.compagnons-devops.fr

Découvre les podcasteurs :
https://lydra.fr/ea-3-le-podcasteur-christophe/
https://lydra.fr/ea-6-le-podcasteur-rene/
https://lydra.fr/ea-2-le-podcasteur-erwan/

Lydra · Juin 29, 2023, 8:36

thierry.f.78 · Juin 30, 2023, 1:37

La rétrocompatibilité avec les processeurs intel 16bit est la pour pouvoir exécuter des vieux logiciels. Dans l’industrie on trouve souvent des vieux truc totalement indispensables mais plus maintenus. On trouve des pilotes de machine outils en 16bit ou des soft sous Windows 32bit, il y a aussi les jeux rétro, les applications métier ou le développeur est partie depuis longtemps, … Donc, la compatibilité ascendante est totalement justifiée, et pas vraiment marginale (sous windows en tous cas).

Pour les anciens, quand tu lancait un jeu sous DOS et que tu voit dos4gw.exe, c’est simplement le programme qui fait passer le fonctionnement du CPU de 16bit à 32bit.

Concernent le DOS, c’est un OS qui a l’énorme avantage de donner un accès complet au hardware. Sous Linux, Windows et Mac (tous les Os multitache), on n’a accès qu’a ce que le kernel veux bien donner l’accès. Typiquement, on n’a pas accès a toute la RAM. Sous DOS, lorsque un soft démarre, il a accès à tout. Aussi, les tests de RAM sont sous DOS (il en existe sous linux, mais ils sont médiocres car ils ne testent pas toute la RAM).

La rétrocompatibilité du x86 en 16bit et 32bits prend très peu de place (elle est gérée principalement par le microcode, et aussi par du mapping d’instructions), et n’impacte pas vraiment les performances. En revanche, elle complexifie énormément l’architecture et ne facilite pas la vie des ingénieurs.

Coté écologie, on parle d’un gaspillage mineur en comparaison a ce qui se fait aujourd’hui:

Coté mémoire, si on force le 64bit, tous les pointeurs de tous les programmes passent sous 8octets au lieu de 4octets pour le 32bits. Excepté pour les programmes qui utilisent un espace d’adressage supérieur a 4Go, on gaspille systématique le double de la RAM nécessaire pour les pointeurs, ce qui est loin d’être neutre (Note: les pointeur existent dans tous les langages au moins au moment de l’execution).
Coté économie de resources, soyons relatifs: faire sa prod en java, ruby ou python, prends 8 à 10 fois plus de resources mémoire et CPU que de la faire en C, C++, Rust ou dans une moindre mesure Go. Or il se trouve que les 3/4 des applications utilisent ces langages de gaspillage de resources. Aussi avant de chercher a supprimer un truc marginal pour économiser un tout petit peu, attaquons nous au gros du problème: lorsque l’exécution coutera plus cher que le développement, on ferra attention a ce que l’on développe.

Coté écologie, la bonne nouvelle n’est pas l’abandon de la rétrocompatibilité x86, mais la généralisation d’ARM.