votre avatar Abonné

Wosgien

est avec nous depuis le 18 mars 2003 ❤️

Bio

Oups.
On dirait que quelqu'un ici aime garder ses petits secrets, comme si de par hasard il y avait quelque chose à cacher...
Désolé, ô lectrice de passage, cher lecteur égaré, pas de révélation sensationnelle pour le moment sur ce profil.
Repassez plus tard ?

3489 commentaires

Hier à 10h 44

D(a)T(a)C(enter) ? :humour:

Merci, c'était mon petit écart du dredi.

Hier à 10h 43

L'Irlande est un paradis fiscal pour tous les GAFAM, grâce à leur politique de dumping sur l'impôt sur les sociétés.
Du coup, fort logiquement, ils localisent leurs activités là-bas, et refacturent à leurs entités européennes en ne laissant le bénéfice qu'au strict minimum dans les autres pays de l'UE.
Pour que ce soit moins "grillé" vis-à-vis des juridictions fiscales, ils foutent tous leurs services en Irlande, call center, ingés, et quand c'est possible, datacentres.

L'Irlande a une politique qui va à l'encontre de l'intérêt collectif de l'UE, et ça paye pour eux, très bien d'ailleurs, ils sont un des états qui génèrent le plus de PIB par habitant, alors qu'ils n'avaient pas beaucoup d'atouts dans leur jeu il y a 40 ans.
Cool pour eux, mais entièrement contraire à l'intérêt général, qui est de taxer la richesse là où elle est produite, et à un taux compatible avec une société bien financée.
Si la dette française se creuse un peu plus tous les ans, c'est un peu grâce à l'Irlande quoi.

N'oubliez pas de fêter la Saint Patrick le 17 Mars prochain.

Oui, j'ai bossé dans un groupe qui globalement faisait du bénéfice mais en France avait gelé les salaires dans ses boites car en déficit.
La raison? Le groupe faisait en sorte que les boites françaises facturent des prestations (RH, com, vente) aux boites irlandaises pour envoyer tous les bénéfices en Irlande.
Dans les bilan, c'était juste évident.

D'autre part, je rappelle tout de même qu'en même temps, le PIB est élevé aussi car ils consomment peu malgré un salaire moyen supérieur à la France. Car le coût de la vie y est élevé (le logement, c'est en gros 40%, les charges fixes de vie comme les abonnements, les mutuelles, 40% plus cher aussi que la France et le reste-15-20% plus cher).

Je répondais surtout sur le côté "bilan écologique" de l'Irlande. J'y ai passé une partie des vacances l'été dernier, ça sentait la misère.

Les datacenter étaient pointés du doigt pour les coupures d'électricité - et les coupures étaient un argument pour faire monter le prix de l'électricité, et chez eux par de "bouclier" de la part du gouvernement. La chasse au gaspi dans les campings était partout - à la limite d'éclairer les allées à la bougie (mais avec leur climat, c'est dans les lamps à pétrole qu'il faut investir).

Maintenant, quand on dit que les datacenters représentent 21% de la conso face à 18% pour l'urbain et 10% pour le rural, ça montre aussi que:
* Rural+Urbain reste > datacenters
* Les datacenters pulullent -> la politique de l'Irlande fonctionne (dounc vu de chez eux c'est bien quand même) et ils ont de l'emploi qualifié et une balance commerciale qui fait pâlir les autres de jalousie (oui, j'ai bien compris la situation, mais c'est vrai, nous sommes jaloux)
* Franchement, si en France on disait que l'industrie a augmenté sa conso électrique de 10%, on y verrait aussi du positif...

Hier à 08h 26

Le climat n'est pas le même. Ni je trouve leur taux d'équipement.

Et franchement, je pense qu'ils consomment moins d'essence aussi: il ne roulent même pas à la limite maxi de vitesse.

C'est plutôt cool l'Irlande. Je ne sais pas si c'était dû à l'été, mais globalement, on a vu que le rythme s'était: boulot, fiesta, boulot. Et un autre boulot le dimanche.

Quand aux équipements: très souvent vétustes pour un frenchy.

Hier à 08h 23

Mon petit doigt me dit que l’intérêt est surtout fiscal…

Et il est où ce petit doigt qui pense au côté fiscal?

Hier à 08h 22

Ou forcer les ménages à consommer plus?

Le 25/07/2024 à 08h 56

Je ne sais pas si c'est un article pour ou contre le RN.
Mais ce qui est certain, c'est que le sujet de l'article c'est le RN: suffit de lire le titre.

Et c'est cela qui m'interpelle.

Le sujet de l'article c'est le milliardaire qui a un plan organisé pour mener le rassemblement national au pouvoir.
Ce n'est pas le RN le sujet.
D'ailleurs, j'ai l'impression qu'écrire "rassemblement national" au lieu de RN aurait adoucit le propos, non?

Mais je te rejoins: je suis obligé de lire 2 ou 3 fois le titre pour reprendre un peu de distance et ne pas me dire qu'il y a une volonté de promouvoir ou nuire au RN (pour tout article qui en parle, quelque soit le média).

Je pense qu'il est difficile de paraître objectif.

Le 24/07/2024 à 17h 03

Je ne suis pas convaincu que le traitement soit politisé. On parle ici d'un magnat, qui finance plusieurs projets numériques et média.
Le fait que ce soit en faveur du RN est fortuit, je pense que c'est l'échauffement dernièrement sur le sujet qui fait penser que c'est un article contre le RN. En plus, avec une source venant de l'huma, ça appuie cette théorie ... mais je ne vois rien dans l'article qui la rend concrète.

Le 24/07/2024 à 12h 02

C'est pas parce que le RN lui semble la meilleure solution qu'il est d'accord avec la totalité. On l'oublie, mais il y a des nuances. On peut mesurer sa compatibilité sur plusieurs axes...

Le 25/07/2024 à 08h 53

On va dire qu'on est sur de la sécu. Que ne pas avoir la conf correspond peut-être à une brèche. Sur ce sujet je leur laisse le bénéfice du doute.

Le 24/07/2024 à 07h 02

Ca c'est vrai. Il est passé où le mode wimboot qui nous permettait de booter directement sur l'image ISO, en dur dans le disque, tout en chargeant "dynamiquement" les modifs passées dans le FS, un peu comme un fichier de modifs?
Ceci dit, avec le boot from VHD, c'est possible depuis Windows Vista: un Windows, un VHD, un disque de différence - et on peut charger plusieurs environnements, revenir à la config d'origine (le VHD), distribuer nue second VHD avec les dernières updates ... Hyper pratique sur des postes "invités"

Ceci dit, en général le mode récup de Windows se débrouille pas mal, mais dans ce cas précis, il ne détecte pas un problème de boot ou un pilote qui fait planter trop souvent, c'est bizarre.

Le 24/07/2024 à 06h 59

Le hook noyau / eBPF est sensé être sûr (code exécuté dans une sandbox, et passé par un vérificateur), et d'ailleurs crowdstrike sur linux semble fonctionner ainsi. Donc a priori, plus safe que sous windows... sauf que même comme ça, ils parviennent à déclencher un kernel panic :ooo: (en théorie ça devrait pas)
cf red hat qui a eu un problème similaire en juin https://access.redhat.com/solutions/7068083 - un patch côté kernel a corrigé le vérificateur eBPF pour ça.

Parce que la partie montée peut être vérifiée/signée et tout c qu'on veut, les fichiers de paramétrage ne le sont pas.
Ce n'est pas "plus safe" que Windows: Windows vérifie des signatures - Linux vérifie au kernel et Windows externalise, c'est tout.

Le 24/07/2024 à 11h 59

Personne n'a forcé Linux ou BSD puisque leur "éditeur" ne propose pas sa propre solution de sécurité, en plus de ne pas être en position dominante. Peut-être qu'une distribution commerciale spécifique autait pu être visée par une telle demande, mais certainement pas Linux ou BSD eux-mêmes.

Oui, c'était ironique. Les solutions EDR fonctionnent sous Linux et BSD sans que l'on considère que ça a affaibli leur sécu. Ms se plaint qu'on la contraint à affaiblir leur sécu - alors qu'on les a juste contraint à permettre aux autres ce qu'ils se permettent tout seuls.

Le 24/07/2024 à 11h 57

A mon avis, c'est loin d'être aussi simple. Pour créer une API spécifique :
- il faut que tout les besoins soient clairement identifiés (ce qui est difficile dans ce genre de situation)
- très certainement remodelé une partie du coeur même du noyau (opération hautement critique).

Sans compter qu'un des points forts de Microsoft reste la rétrocompatibilité. Faire un tel changement aurait sans doute cassé quelques trucs. Je ne connais pas beaucoup d'OS qui permettent de prendre un programme vieux de 25 ans (par ex. sous Windows 98) et de le faire tourner sur un Windows 10 ou 11 juste en cliquant dessus (et non, Linux ne rentre pas dans cette catégorie, il faudra au mieux recompiler le programme si tant est que l'opération reste possible).

Faire en sorte que sa solution soit au même niveau que les autres, c'est potentiellement abaisser la sécurité globale du système. Pas vraiment souhaitable donc.

Rendre les solutions plugables dans Hyper-V n'aurait pas résolu les problèmes. Pour ce qui est virtualisé, sans doute. Pour le reste non.

Là, on est dans une situation qui est un bel exemple de la Loi de Murphy. La situation a été catastrophique, car :
- le driver est un driver noyau
- la solution est très répandue
- la solution est utilisée dans des infrastructures visibles (aéroports, hopitaux, etc.)
- la gestion de la mise à jour est faite par l'éditeur
- un driver en espace noyau lit un fichier de configuration en espace utilisateur
- l'éditeur pousse une mise à jour d'un fichier de configuration chez tous ses clients en même temps
- les clients n'ont pas vraiment de moyen de contrôler la mise à jour de ce fichier de configuration
- la mise à jour faisait planter quasi-systématiquement le système (au point qu'on se demande si elle a été testé !)

Enlève ne serait-ce qu'un de ces points, et la situation critique que nous avons connu il y a quelques jours n'aurait pas eu lieu.

L'argument avancé par Microsoft peut tout à fait tenir la route (je n'ai pas suffisamment d'éléments pour dire si c'est effectivement le cas ou non). Je dis juste qu'il est tout à fait plausible, et le démonter ne sera pas si facile que ça.

[edit]
Par contre, un truc qu'aurait pu faire Microsoft, et cela, sans nécessiter a priori de modification profonde, c'est de détecter ce genre de redémarrages intempestifs pour proposer un démarrage en mode sans échec. Ce qui ne semble pas être le cas ici.

Je suppose que c'est parce que le système avait le temps de booter entièrement.

Je suis modérément d'accord. Avec l'UEFI, on a des solutions pour injecter assez bas des drivers/firmware.
Par ailleurs, le noyau Windows a largement évolué: la compatibilité des anciennes applis reste du haut niveau - assez peu dépendant du noyau en fait même si s'appuyant sur certains mécanismes.
Hyper-V est actif sur de nombreux ordis et un Windows qui héberge WSL n'est pas tout à fait un hôte (cf le fait que la gestion d'énergie et d'autres subtilités sautent sur beaucoup de config si hyper-v est actif) - oui, Hyper-V est bien SOUS l'instance Windows qui tourne et a le privilège d'accéder au clavier physique et à la partie graphique. D'ailleurs, plusieurs solutions de sécu de MS sont basées sur l'activation de cette virtualisation.

Sans parler de toutes les sondes intégrées - Windows est un OS plutôt ouvert sur le suivi, avec une structure commune.

Il y a certainement des TONNES de solutions autres. Ms a certainement choisi celle qui l'arrangeait le plus pour fustiger ce qu'on lui a imposé. On a vu assez de rootkits avant même la demande de l'europe pour savoir qu'il y a des solutions pour s'intercaler sous l'OS dans le noyau et surveiller les applis. Cf les anticheats et DRM.

Pour le redémarrage en mode sans échec, il existe, et aurait dû se déclencher. Je pense que le pilote falcon déclare avoir démarré AVANT d'avoir lu la config et planté - dans le cas d'un pilote qui n'arrive pas à démarrer, Windows peut le virer automatiquement. Ou alors Crowdstrike a fait en sorte que justement on ne puisse pas désactiver le pilote en bidouillant les fichiers - auquel cas je reviens au produit Falcon qui devrait se mettre en mode sécu tout seul et isoler proprement le poste avec une manip pour se reconnecter.

Le 24/07/2024 à 06h 51

Et qui a forcé Linux et BSD à abaisser leur sécu pour que les solutions de sécurité soient au même niveau ?
Une autre solution pour Ms, plutôt que de permettre (forcer) n'importe quelle solution de sécurité (hum - y compris les gestionnaires de DRM) à devenir des rootkits, ça aurait été de mettre SA solution de sécu au niveau des autres au lieu de la mettre dans le noyau... Ou de la partager, si c'est le noyau...
Ou de rendre les solutions plugables dans Hyper-V si on veut un genre de rootkit...

N'importe quel spécialiste pourrait démonter cet argument je pense.

Le 24/07/2024 à 06h 53

Adieu les fond d'écran coeur pour la St Valentin?

Le 23/07/2024 à 10h 49

Oui c'est qu'une winpe avec un prompt de bitlocker et un "DEL" intégré... ça a l'avantage de pouvoir faire gagner 20% de temps (pas à lancer l'explorateur et à chercher le fichier et le péter)
il y a surement la version de la N*A avec bypass bitlocker, mais ils se sont dit que diffuser la clé magique qui déverrouille tous les disques ça la foutait mal :D

Bref, un bon virus aurait fait autant de dégâts (voire moins).

Le 23/07/2024 à 10h 47

La ROM du 464 a plusieurs bug dans son Basic (version 1.0) , je pense qu'ici tu fais référence à l'instruction DEC$ qui réclame deux parenthèses ouvrantes dans cette version.

Ouiiii, merci!!! Je ne retrouvais plus :) Je savais que c'était une instruction genre DEC mais je n'ai pas le mode d'emploi papier sous la main.

Le 22/07/2024 à 09h 10

L'amstrad CPC avait un bug dans sa rom, pour une des fonctions du basic il ne fallait pas fermer la parenthèse.
Amstrad a tout géré à la Amstrad: correction (manuelle au début) du mode d'emploi pour l'indiquer.

Le 19/07/2024 à 14h 51

Ce n'est pas comparable, Apple supporte un nombre limité de machines.
La plupart des autres OS (Windows, Linux et autre) sont plus permissifs sur ce que tu peux installer, mais cela implique d'être plus responsable sur ce qu'on installe.

C'est clair, ils doivent pouvoir créer une image OS par modèle supporté chez Apple. Ca fera quoi? 100, 200 images?

Le 23/07/2024 à 10h 46

Mais la question n'est pas de faire un catch, mais quoi faire du catch ? Si vous décider de poursuivre l'exécution alors que l'état du programme est incohérent, vous n'aurez rien résolu du problème initial et vous déplacez le problème ailleurs. S'il y a un écran bleu sous Windows, ce n'est pas parce que le noyau fonctionne mal (ou pas forcément), mais parce que le noyau est arrivé dans un état incohérent où il ne peut poursuivre son exécution sans potentiellement aggraver le problème. Un catch pour empêcher l'écran bleu ne changerait rien au fait que cela n'aurait pas du arriver dans le sens où le bug n'a pas été anticipé (sinon, il n'y aura pas de bug en fait).

Ce qui peut arriver à l'échelle du noyau peut aussi arriver à l'échelle d'un programme. Faire un catch de quelque chose d'incohérent dans le contexte, ne changera rien au fait que cela n'aurait pas du arriver. Et donc, dans ces conditions, il vaut mieux que tout plante plutôt que continuer l'exécution avec un cas non prévu. C'est tout ce que j'ai essayé de dire, et c'est pas la peine de me prendre de haut en entrant dans les détails technique du C pour noyer le poisson dans l'eau. Ce que je dis est une banalité. Votre façon de me rabaisser est intolérable.

"Mais la question n'est pas de faire un catch, mais quoi faire du catch ?"
La réponse appartient au programmeur.

Si c'est dans une section de lecture des paramètres, ma réponse la plus simple est: "application des paramètres de repli".
C'est le cas dans je pense 99% des mes dev depuis 25 ans.
En gros: on commence un dev: on met des paramètres par défaut intégrés dans l'exe (genre mode sans échec), modifiables par fichier de config, un général et un user. Le fichier d'origine fourni pour overrider le défaut peut être celui qui déclenche le 1er paramétrage par un admin. Ou pas.

Planter tout n'est pas une option à ce niveau - bloquer l'ordi, signaler au centre ce commande, utiliser un broadcast/multicast pour se signaler et choper une vraie config ... il y a tant de choix du plus simple au plus complexe.

Euh, ils ont choisi l'amateurisme. Même mes dev IOT à la maison ont un mode fallback.

Quand on développe niveau noyau ou pilote, oui on teste pleins de cas d'erreur pour ne pas tout planter.

Le 22/07/2024 à 16h 59

D'autre part, vous proposez des tests pour éviter le problème dans le code en production, mais vous ne pouvez pas faire un try/catch à chaque fois que vous lisez une variable. Et même si vous le faites, il faut vous attendre à deux catégories de problèmes ; les exceptions (ouvrir un fichier qui n'existe pas), ou les erreurs (arriver à un état du programme qui n'aurait pas du arriver). A moins de considérer qu'une mauvaise adresse mémoire pointé par une variable soit un comportement normal, il s'agit au tout état de cause d'une erreur et non d'une exception. Dans ce cas, quand un programme génère une erreur, il faut laisser le programme planter et ne surtout pas continuer l'exécution pour éviter qu'un comportement improbable (et pire) ne se produise. Donc même si vous faites un try/catch, si ça ne doit pas arriver, il faut quand même terminer le programme. Le try/cath ne servirait dans cet exemple qu'à journaliser la trace de l'erreur et/ou à fermer correctement les verrous obtenus sur le système.

Le sens de mon premier commentaire était de dire que les langages C et C++ ne génèrent pas les mêmes exceptions en fonction de la configuration mémoire dans laquelle on se trouve à cause du laxisme des deux langages dans la gestion de la mémoire, ce qui pose problème quand on test le programme, que le test est validé dans un environnement et que l'erreur se produit quand même quand l'environnement et la configuration mémoire du programme changent, i.e. lorsque le programme passe en production. Ce type de problèmes intempestifs ne se produit pas dans d'autres langages de programmation, où la gestion de la mémoire est plus cadrée. Maintenant, je n'ai pas dit que c'est ceci qui s'est passé dans le cas de cet article d'où le "peut-être" dans mon premier commentaire.

Aller, je craque:
"D'autre part, vous proposez des tests pour éviter le problème dans le code en production, mais vous ne pouvez pas faire un try/catch à chaque fois que vous lisez une variable."

Non, question de contexte, mais en général on englobe toute un section de code.

" Et même si vous le faites, il faut vous attendre à deux catégories de problèmes ; les exceptions (ouvrir un fichier qui n'existe pas), ou les erreurs (arriver à un état du programme qui n'aurait pas du arriver). A moins de considérer qu'une mauvaise adresse mémoire pointé par une variable soit un comportement normal, il s'agit au tout état de cause d'une erreur et non d'une exception."

C'est une bonne remarque. Si les environnements managés (java, C#) considèrent à peu près pareil et gèrent de la même façon les erreurs de pointeur et les erreurs "managées", ce n'est pas pareil en C et en C++ (qui eux-mêmes sont différents).
Quand je parlais de try/catch, c'était sur l'idée générale.
Et donc c'est une mauvaise remarque: en C, on peut aussi dire comment le soft doit gérer les exceptions SYSTEMES (div/0, accès mémoire illégal, instruction illégale). Ce qui fait l'équivalent d'un try/catch (je ne me rappelle plus bien, je n'ai pas fait de C de ce genre depuis 2000).
On ne peut pas catcher toutes les erreurs mémoires, mais quelque soit le système, taper dans la RAM système (comme 0x9c) est catchable. Ce qu'on ne peut pas détecter ainsi, c'est quand le programme écrit trop loin dans sa propre mémoire.

Bref il y a des mécanismes basiques, en place depuis le début de la "mémoire protégée" qui existent en quasi standard.

Donc de la part d'un programmeur d'EDR, c'est pour moi impardonnable.

Le 22/07/2024 à 16h 47

D'autre part, vous proposez des tests pour éviter le problème dans le code en production, mais vous ne pouvez pas faire un try/catch à chaque fois que vous lisez une variable. Et même si vous le faites, il faut vous attendre à deux catégories de problèmes ; les exceptions (ouvrir un fichier qui n'existe pas), ou les erreurs (arriver à un état du programme qui n'aurait pas du arriver). A moins de considérer qu'une mauvaise adresse mémoire pointé par une variable soit un comportement normal, il s'agit au tout état de cause d'une erreur et non d'une exception. Dans ce cas, quand un programme génère une erreur, il faut laisser le programme planter et ne surtout pas continuer l'exécution pour éviter qu'un comportement improbable (et pire) ne se produise. Donc même si vous faites un try/catch, si ça ne doit pas arriver, il faut quand même terminer le programme. Le try/cath ne servirait dans cet exemple qu'à journaliser la trace de l'erreur et/ou à fermer correctement les verrous obtenus sur le système.

Le sens de mon premier commentaire était de dire que les langages C et C++ ne génèrent pas les mêmes exceptions en fonction de la configuration mémoire dans laquelle on se trouve à cause du laxisme des deux langages dans la gestion de la mémoire, ce qui pose problème quand on test le programme, que le test est validé dans un environnement et que l'erreur se produit quand même quand l'environnement et la configuration mémoire du programme changent, i.e. lorsque le programme passe en production. Ce type de problèmes intempestifs ne se produit pas dans d'autres langages de programmation, où la gestion de la mémoire est plus cadrée. Maintenant, je n'ai pas dit que c'est ceci qui s'est passé dans le cas de cet article d'où le "peut-être" dans mon premier commentaire.

Je n'avais pas l'intention de déclencher un cours de prog. La gestion des erreurs, c'est un indispensable, il faut bien établir où sont les sections critiques et comment en sortir proprement.
Bien spur, dans le cas d'un EDR, s'il suffit de pourrir son fichier de config pour le désamorcer, c'est balo. La bonne pratique que je conseille dans ce cas: livrer la config par défaut, si erreur de lecture du fichier de config on tombe dans la config par défaut.

On en revient à la base de la programmation, y compris en automatisme: sortir de l'erreur sans tout péter. cf le cas du Therac-25. C'est en gros la même chose à vue de nez.


Parfois les grands éditeurs me font plaisir en programmant moins bien que moi et mon équipe :)

Le 22/07/2024 à 09h 23

Un test "!= null" ou un try/catch, c'est pas hors de portée non plus.

Ce bug, bien que minimisé dans les médias, aura de lourdes répercussions. Quand un bug touche uniquement les techs, ça va, c'est une mauvaise réputation chez les techs. Quand ça atteint les utilisateurs, on en est pour 5 à 10 ans de perte de confiance.

Quand un employé perdu utilise le joker "on a un problème informatique" au téléphone avec un client, l'employé DOIT avoir mauvaise conscience. Là, il pouvait fièrement le dire. On n'est pas près qu'il se repose des question sur son usage: ce sera l'ordi qui bug/se trompe/lag/freeze.

Le plus gros mal en informatique, c'est le peu de confiance qu'ont les utilisateurs dans l'outil, souvent par manque de formation.
C'est un énorme travail de la part des chefs de projet pour animer cela et rendre la confiance dans l'outil. On doit souvent se porter "garant" du résultat.
Le moindre faux pas, le moindre résultat inexpliqué et c'est comme un lent poison pour le projet.

Résultat: si l'outil n'est pas fiable, pas la peine de passer du temps dessus - et on se retrouve avec un outil dont les données sont pourries, inutilisable, rejeté. Du coup, on se voit obligé de changer d'outil parce que le directeur des employés l'exige - pour un outil moins bon parfois mais qui était dans les pages de 01informatique.

Bref, l'étendue de cet incident est bien plus large que 8,5M ordinateurs: que ce soit de bonne ou mauvaise foi, les reprogrammations de visites à l'hôpital, les retards logistiques, les décalages dans les transports ne se résolvent pas en prenant le prochain horaire: c'est plusieurs jours de replanification!

Je rappelle que Crowdstrike est censé garantir disponibilité et uptime. Là, leur bug est l'équivalent EXACT d'une attaque de virus réussi pour une équipe informatique. Sans parler qu'avoir un EDR, c'est une charge de travail de maintient supplémentaire pour débloquer les postes injustement bloqués, et une gêne régulièrement dans l'usage des ordis + une charge en ressources informatiques...

La com de Crowdstrike me paraît du coup totalement décalée. Le PDG devrait démissionner, la boîte offrir l'année de presta et baisser le coût de moitié: l'attaque qu'elle vient de faire surpasse largement un gros virus tellement c'était étendu et généralisé. Ils viennent de prouver qu'ils sont aussi dangereux que les attaques contre lesquelles ils sont censés nous prémunir.

Le 19/07/2024 à 07h 27

Entre celui qui se fait coincer par le FBI et celui-là, je dirais méfiez-vous de vos employés formés par l'Epitech.

Le 18/07/2024 à 17h 42

"le problème c'est que Windows, c'est plusieurs centaines de millions d'utilisateurs voire milliards. donc les problèmes ont plus de visibilité que Linux ou Mac qui sont loin derrière en terme de part de marché."

Ça dépend comment tu comptes. Les estimations du nombre de machines Windows tournent autour de 1.4 milliard. Rien que chez Docker, on estime à 700 millions le nombre de déploiements, et Datadog estime le nombre de containers à 2.4 milliards dans le monde. Si on ajoute tous les serveurs hors containers, les OS embarqués de la plupart des box et routeurs (il y a aussi du *BSD dedans, certes), et les 3 milliards d'android qui, après tout, sont des Linux, la conclusion n'est pas si évidente que Windows est devant.

Sauf qu'on ne met toujours à jour les Linux (Android, voiture, vidéo proj) ou partiellement (docker, VM fournies par les éditeurs qui ont 3 ans de retard...)

Et si on compare, des windows server qui tombent c'est très très rare (et encore plus rare sur du windows server core).

Le 18/07/2024 à 17h 13

j'ai vu les résultats dans sccm avec leur dernière invention il y a env 1 an
un kb de 725Mo dans le catalogue c'est 9.9 go dans sccm car ces boulets y ont intégré les features on demand (env 5.7+2.5go) dans tous les kb cumul intégrés dans sccm

extract de sccm sur le KB5040442
| fichier | taille |
|http://../.../public/featureondemand_3294af9937b733783476da837b21943dc160faaa.wim | 5747,73 |
| http://../.../public/edition_b7d4cae381a5971e5bf48a1246488c4e7861a0b0.wim | 2506,84 |

Je suis bien content de ne plus m'occuper de cela :)

Le 18/07/2024 à 06h 56

Je rajouterais, tu veux quand même pas demander à MS de faire un vrai OS par hasard. Un truc qui marche correctement (par rapport à un Linux) et pas une daube sans nom.

Windows est un vrai OS qui tient a route ... Et bien mieux documenté pour une entreprise que Linux, et plus stable dans le temps sur bien des points.
Si tu veux un vrai conccurent à Windows dans l'entreprise, ce serait FreeBSD, ou Readhat, ou Oracle ou Debian, pas "Linux"

Le 18/07/2024 à 06h 54

J'ai compris autre chose (mais aussi sur la base d'autres articles précédents): Microsoft veut casser les "paquets": dans les différents paquets, souvent des fichiers sont identiques aux précédents, l'idée est de ne plus les envoyer mais d'envoyer uniquement les fichiers différents.
Ca ne change pas le repository des paquets.

Ce qui va exploser ton SCCM, ce sera la montée des paquets ARM en plus de X64 et x86 s'il t'en reste.

Pour les linuxiens, c'est comme si on ne récupérait pas tout un deb mais uniquement les fichiers différents. Ou si pour mettre à jour un snap on ne retéléchargeait que des morceaux.

Le 16/07/2024 à 11h 51

Bah, sous Windows 3.1 (qui n’était qu’une GUI pour DOS, qui restait le vrai OS), c’était le cas d’un peu tous les périphériques, hein… Mais tu fais une relation de cause à effet qui ne va pas de soi, dans ton message : si Windows lui-même n’était pas conçu pour gérer les CD, peu importait que MS-DOS, lui, y arrivât.

Pff... DOS ne gérait pas TOUS les périphériques, uniquement le stockage et la saisie. Il ne gérait absolument pas par exemple: le son, les imprimantes qui étaient gérés par les softs (ou par Windows, qui lui avait des pilotes déclarables dans le system.ini, win.ini et dans certaines sections comme 386enh) ou le réseau (introduit de mémoire par Windows 3.11) - sauf à mettre une couche novell

On ne peut pas dire que Dos "gérait" le port série ou le port parallèle qui étaient implémentés en dur par le BIOS.

Ca met Windows 3.1 tout à fait en position légitime pour être un OS, même si une partie reposait sur DOS - à ce niveau DOS était à peine plus évolué que le BIOS.

La principale partie un peu intéressante sur laquelle Win3 se basait, c'était le pilote EMM386 :)

Il me semble que Quake 1 DOS, pour le faire fonctionner en réseau, nécessitait un "pilote", mais c'était assez factice car la couche réseau n'existait pas sauf via novell.

Le 16/07/2024 à 11h 43

Je me suis trompé d'article :sm:. L'article d'aujourd'hui qui parle d'Opéra citait Startcounter.

Ça ne change rien à la première partie de mon commentaire, par contre, la fin est hors sujet (sauf l'histoire des postes caisse, je ne suis pas sûr qu'ils aient un navigateur).

Certains ( :) ) utilisent le poste caisse pour simplifier l'accès - et afficher intranet, accès à d'autres applis comme les prises de congés... Sans compter l'accès à des systèmes intermédiaires pour certains moyens de paiements validé en ligne ou autrement et pas directement intégrés dans le soft.

Le 15/07/2024 à 15h 48

Je pense que plus d'1,5 millions de sites répartis dans le monde, c'est suffisant pour avoir des statistiques fiables. En plus, Opéra doit se moquer des cas que tu cites (en particulier les "postes caisse" qui m'ont fait sourire par rapport au sujet de la brève).

Tu voulais dire "Mozilla" au lieu d'"Opera"?
Aucune idée, on ne sait pas quelles sont les arguments qui ont abouti sur cette annonce (stratégie ou concours de circonstance?)
Pour les postes caisses: c'est plus facile de pousser un firefox par copier/coller qu'un EDGE pour permette l'accès depuis un Windows POS ou Embedded à un intranet récent :)

Pour statcounter, je n'arrive pas à savoir quels sont les sites utilisés. Par exemple, je n'utilise pas le même navigateur pour utiliser les applis SAAS du boulot et pour surfer.

Je suis convaincu que statcounter donne la bonne tendance, mais je pense que les chiffres entre poste pro et perso sont différents - et que statcounter a des infos "perso".
Mais je me trompe peut-être (je n'ai été que dans des boites très conservatrices, le SAAS c'est encore un peu l'exception)

Le 15/07/2024 à 10h 46

Statcounter est une "réalité" très imparfaite: elle représente les stats des ordis qui se connectent à internet ET sur des sites statcounter.

Il existe des Windows 7/8/8.1 en activité qui ne sont PAS référencés par statcounter (je pense à pas mal de postes caisse).

Firefox ESR peut servir en intranet, pas forcément connecté sur internet, pour être utilisé pour accéder à des
applis internes vieillissantes - ou simplement parce que Chrome même en version entreprise est un peu lourdingue.

Le 13/07/2024 à 17h 00

400k km et 15 ans ce n’est pas nécessairement incompatible avec l’électrique imho, c’est même plutôt un des points forts de cette technologie.
La réparabilité à 15 ans est incertaine avec tous les constructeurs actuels tellement ça bouge en ce moment, en thermique et en électrique.

D'où l'attente de voir qui s'en sort... 15 ans, c'est certainement un achat de batterie sur la vie du véhicule. Mais si dans 10ans les pièces sont indisponibles, c'est nyet.
Le marché est encore jeune, plein de marques, on dirait l'informatique dans les années 80 ou la hifi dans les années 70. Ou les smartchoses dans les années 2000.
Et on sait comment ça a fini pour beaucoup de produits (bons et moins bons)

Le 12/07/2024 à 20h 50

BYD maîtrise sa chaîne dappro. Ils font l'ensemble de leurs pièces sauf vitres, pneus et essuie glace. Lors de mon achat, j'ai posé cette question et mon concessionnaire BYD m'a montré qu'il avait déjà en stock pas mal de tôlerie etc. Et puis j'ai repensé à mon changement de portière de la Honda Civic il y a 10 ans. 1 mois pour avoir ne serait-ce que juste la pièce.

Dans l'automobile il y en a pour tout le monde. Si tu cherches un véhicule pour aller fun point À à un point B et que tu te fou du reste, tu prends la moins chère et ballec si c'est pas confortable toussa. Si tu cherches un peu de qualité et que tu fais gaffe à ton budget, les Chinois sont très bien placés. Si tu as pas de limites, tu va chez Tesla, Audi, BMW, Porsche etc

Je cherche la voiture qui durera 15 ans et 387000km. C'est mon rythme. Donc là, l'électrique, c'est pour le moment compromis.
Avoir du stock au début d'un produit, c'est bien, mais c'est pas le moment :) Sans compter que beaucoup de concessionaire sont "en sous main", et qu'ils envoient les voitures électriques se faire réparer ailleurs (y compris renault ici)

Le 12/07/2024 à 20h 46

En avion j'aimais bien égayer une morne navigation d'un tonneau barriqué... a moto plus jeune et affûté physiquement des pointes à ce niveau étaient fréquentes pour les mêmes raisons. Y compris quand des conditions très favorables ne voyaient pas souvent la vitesse baisser sous les 180-200km/h, ce qui peut déjà sembler pas bien morne mais c'est comme tout: Une question d’entraînement et d'habitude.

Par contre, je n'ai jamais volé avec une voiture ou une moto. La seule restitution qui fonctionne, c'est un bon usage de la coupure d'injection en anticipant énormément. Ce que plus grand monde ne sait faire, faut dire que pour se traîner à 80 en comptant les trèfles sur le bas côté (pour éviter l'endormissement) ce n'est plus vraiment perçu comme vital (à tords, d'ailleurs les chiffres récents démontrent que l'homéostasie du risque est têtue).

Les gens savent faire. Simplement sur route on ne joue pas avec la vie des autres. Rouler à 170-180 c'est facile, je l'ai aussi fait dans ma jeunesse. Mais comme c'était en AX 50CV ça m'a fait réfléchir...
Pas mal de gibier ou d'enfants évités à peine à 50km/h aussi ça remet en question.

Je préfère me défouler au karting, ou u jour j'espère sur circuit. Mais sur route, je respecte pour moi et les autres.

Quand à ceux qui "roulent", on distingue souvent leur arrogance: fiers de doubler en situation dangereuse, incapables de voir que leur manoeuvre n'a pu aboutir que parce que les autres, à 80-90, ont dû ralentir.

Jusqu'à ce que je sois témoin d'un accident complètement stupide lié au comportement idiot d'un conducteur qui se croyait tout puissant avec son audi.
Mais j'ai pu constater que la gendarmerie sait les remettre à leur place et pointer leurs responsabilité dont ils se défaussent...

Bref, je me moque toujours de ceux qui sont fier de leurs capacité sur route. J'ai rencontré des gamines de 17 ans, licenciées de rallye, qui leur feraient ravaler leur ego avec des voitures 2 fois moins puissantes :)

Le 11/07/2024 à 22h 37

Tout à fait. Quelque soit le produit, l'argument n°1, c'est le prix.
Mais quand même: tu as confiance dans la chaîne d'appro pour les réparations d'un véhicule électrique?

Perso le marché me fait penser à l'informatique en 1985: plein de produits, plein de marques, mais qui va finir par gagner? (si c'est comme l'informatique, ce ne sera pas Tesla, mais plutôt Dacia :) )

Le 11/07/2024 à 22h 32

Si je pars assez tôt pour être arrivé entre 12h et 13h, je me contente d'un arrêt pour pisser si j'ai pu rouler à bon rythme. Sinon je sors de l'autoroute pour éviter le restoroute tricatel. Je me suis reposé avant, je ne pars jamais le soir par exemple et préfère me coucher pas trop tard quitte à ce que cela ne soit que pour 5h.

Et puis il faut suivre: si tu calcules bien, en roulant à 260, tu arrives parfois à voler, c'est autant de carburant d'économisé quad tu planes.

Le 10/07/2024 à 22h 15

Comment ça peut être un argument de vente ? 😅

Par exemple quand tu es abonné instant ink, la connections au moins hebdomadaire est obligatoire pour détecter le manque d'encre et envoyer la nouvelle cartouche ... Et pour la facturation à la page, pour vérifier que la cartouche installée est bien la tienne, car la cartouche qu'ils t'envoient est liée à ton imprimante.

Epson 'ous a fait le coup au travail il y a quelques années: envoi de cartouche taggée our ne fonctionner que dans un imprimante donnée... Mais envoi de toutes les cartouches au siège sans moyen de les distinguer...

Le 09/07/2024 à 13h 24

Pour valider que la cartouche est légitime entre autres.

Le 09/07/2024 à 13h 23

C'est pas du laser, mais un voisin a acheté une HP avec cartouche instant ink en soldes.
Impossible de la configurer. Elle veut se connecter à internet, mais refuse d'être associée à un compte instant ink. Il faut lui passer une mise à jour firmware, qu'elle refuse de faire tant qu'elle n'est pas connectée à un compte instant ink...
Elle refuse de démarrer sans cartouche...
C'est pas pensé à fond tout cela. Par contre je suis abonné instant ink pour la mienne, et j'adore....

Le 10/07/2024 à 22h 02

Un tidy et un inventeur pour le XML, Json et autres... Et un onglet qui affiche dès qu'on arrive sur le bloc noté le contenu du presse papier

Le 10/07/2024 à 22h 01

À dire vrai, le Bloc-notes actuel est très bien. Les fonctions ajoutées sont discrètes et ne ralentissent pas l’appli. On ne peut pas vraiment parler de vitesse d’ailleurs, c’est instantané.

Du coup il faudrait qu'ils arrêtent de l'évoluer pour éviter les bugs et ralentissements, non?

Le 10/07/2024 à 22h 00

Je me faisais justement la réflexion que plus les versions de Windows évoluent (7,8,10,11) et plus j'utilise des programmes tiers à la place des outils préinstallés.

Ca devient l'enfer d'utiliser les outils préinstallés pour gérer les partages réseau, le firewall, les taches planifiées, les comptes utilisateurs, les mises à jour, ...

Utilises la ligne de commande. J'utilise encore des commandes rôdées sous windows 2000. Ça ne bouge pas trop et on voit ce qu'on fait.

Le 10/07/2024 à 17h 00

J'attends LA feature façon MS: le masquage automatique des mots de passe dans les fichiers de config. Je leur ai soumis l'idée, on va voir s'ils mordent à l'hameçon.

Le 10/07/2024 à 21h 46

On étudie comment intégrer les ia au boulot. Si les llm sont ce qui est le plus demandé (rédaction et synthèse de texte -à se demander si on ne va pas demander à une ia de rédiger pour qu'une autre synthétise de l'autre côté), ça ne me paraît toujours pas ce qui est le plus intéressant.
Je pense que les modèles d'extraction d'info, et la compréhension et synthèse du langage pour supprimer le clavier, aider à vérifier les infos sont tout aussi intéressants, voire plus.

Le 10/07/2024 à 21h 41

Je n'ai pas lu le rapport. Toutefois on connaît déjà les limites de l'IA générative (actuelle): résultats non prouvables, périssement des modèles (entraîner une ia, très peu peuvent le faire et c'est très coûteux), coût énergétique fort, et nombreux risques juridiques/légaux non levés.
On est sur de l'investissement à risque dans lequel il faut vite faire du profit et quitter rapidement.

Je suis convaincu qu'il y a une bulle de l'IA: les entreprises sont en train d'essayer de récupérer du cash sur l'investissement initial, mais les innovations à venir sont nombreuses et vrisquent de rendre obsolètes les modèles actuels: nouveaux modèles correctibles en live, plus analysables, modèles mathématiques moins gourmands, modèles spécialisés léger au lieu de grosses machines insondables, modèles compatibles culturellement....

Le 10/07/2024 à 17h 06

Justement, c'est le propos:
* Les chinois ont subventionné les véhicules électrique pour innonder le marché
* Nos constructeurs locaux n'ont pas pu suivre les prix à cause de ces subventions
-> Le marché est cassé par les chinois

* MG n'absorbe pas la hausse à ce que je comprends, mais l'amorti avec les véhicules déjà en stock en europe et en stock sur la zone d'échange euro (comprendre: ils vont passer les véhicules par la Norvège et UK qui vont les "blanchir" de la taxe, car elle ne s'applique qu'en direct Chine -> pays européen)

Bref, rien n'indique que les marges sont si démesurées.

D'autre part, une marge c'est confortable quand on n'a pas de dette et de charge ... Une marge de 100% dans l'alimentaire sur un produit, c'est assez courant et nécessaire pour obtenir 1 à 2% de résultat positif en fin d'année.

Le 08/07/2024 à 10h 07

J'ai une politique no-CDN en dev. Et très forte limitation des dépendances (quand on arrive à suivre qui dépend de qui...).

Du coup, mes applis sont moches, semblent vieilles, mais ... elles fonctionnent internet coupé.

Ma dernière découverte (car au boulot nos sites DMZ n'ont par défaut pas le droit d'aller sur internet): Wordpress dépend d'internet, mais ses plugins, c'est pire! Et encore, quand ce n'est pas le presta lui-même qui héberge des scripts chez lui.

Vivement NIS2!

Le 04/07/2024 à 07h 55

On nous a alerté sur le coût d'un recherche google. Sur le coût d'un email. Maintenant, on va pouvoir évaluer le coût de faire générer des courriers par une IA qui seront synthétisé par une seconde.

Le 02/07/2024 à 09h 08

Celle-ci? https://fr.wikipedia.org/wiki/Droit_%C3%A9lectoral_(nouvelle)
Merci pour la decouverte, je vais rapidement lire ça

Oui, ça doit être cela: je l'ai effectivement lue dans "Histoires de demain"
1 2 … 69 70