A la fin de l'article, il cite une des réponses qu'il a eues:
A Chromium-only web is definitely not a goal, but I, at least, see it as fairly likely to happen anyway. I see 4ish possibilities […]
Traduction vite faite, mal faite: ce n'est définitivement pas un objectif, mais ça va arriver de toute façon.
Et ça me paraît clair aussi, depuis longtemps. Tout le monde s'est réjouit de la mort d'IE, je pense que des gens devaient aussi être assez content qu'opera cesse de maintenir son moteur… on a perdu au moins 2 implémentations (et implémenteurs!) alternatives en 10 ans, et aucune nouvelle n'est apparue.
Il ne reste que webkit poussé par Apple (et encore, je ne suis pas sûr qu'ils reversent tout dans webkit, vraiment pas sûr) et gecko. Webkit est la racine de blink (même si depuis le code ne dois plus avoir grand chose en commun, à part l'architecture peut-être), donc on peut en arriver à la conclusion qu'il ne reste vraiment que 2 implémentations hautement conformes, et vu comment la complexité de l'usine à gaz ne cesse d'augmenter, je doute fort que ça ne change.
Le mobile émettra une sonnerie distincte, même en mode silencieux. Celle-ci ne s’interrompra que lorsqu’on consultera le message.
Y compris quand les gens sont en train de conduire donc. Devoir manipuler son smartphone au volant, c'est:
accidentogène, surtout quand le truc gueule comme un putois ce qui stresse bien;
dangereux pour le permis, parce qu'on sait jamais ou les flics se planquent;
Une multitude de risques seront susceptibles de faire l’objet d’une alerte, […] accidents graves sur les réseaux routiers, ferroviaires ou aériens […] Ainsi, évidemment, que les événements graves de sécurité publique, comme les attentats
La porte ouverte au flood tout ça… Je plains les parisiens, parce qu'avec le traffic qu'ils ont, ça risque de sonner souvent pour cause d'accident de la route.
Quel sera le degré de précision des alertes ? La zone minimale couverte sera celle qu’une antenne est capable de couvrir, variant de cinq kilomètres de rayon en campagne
Bonne portée en plus. Du coup, les autoroutes, campagne ou pas?
A Hawaï par exemple, en 2018, un test de routine a débouché par erreur sur l’envoi en masse d’une alerte nucléaire, provoquant des scènes de panique. Pour éviter ce scénario, « les messages de test ont été rédigés avec une charte graphique spécifique, ils mentionnent clairement qu’il s’agit d’un exercice »
les problèmes de l’application SAIP […] l’Etat a aussi une part de responsabilité [dans les problèmes]
La formation du grand public importe, elle aussi. « Il faut que chaque citoyen reçoive au moins deux à trois messages par an : la répétition fixe la fonction »
Sachant que c'est à la charge des préfectures, suffit d'avoir le bon préfet et ça risque d'être vite fait le carillon…
Sinon, moi je bosse dans des sites indus, et concrètement, le jour ou une sonnerie ne sera pas une sonnerie de test, je suis curieux de voir si elle servira a quelque chose.
Les gens sur un seul site en permanence, eux sauront, certes, mais a vue de nez la masse des travailleurs viens de l'extérieur, et dans mon cas cette année j'ai déjà "visité" 5 sites, chacun avec ses moments de tests différents. Le jour ou ça sonne pour de vrai, je serai incapable de savoir si c'est une sonnerie de test ou pas.
Du coup, si jamais ils s'amusent a flood leurs alertes, ce qui me surprendrais pas vu les délires sécuritaires de partout (qui, ici, considère qu'une alerte orange météo france mérite de s'y attarder? Vigipirate, ça vous parle? Dans un site Seveso, en cas d'attaque terroriste, il faut se cacher… comme ça le mec a le temps de faire péter le pipeline sans être emmerdé!) ça risque bien d'être juste du bruit.
Mais bon, par chance:
laissera de côté au moins un quart des appareils en circulation. Sont exclus les téléphones mobiles ordinaires : un Français sur dix est équipé d’un de ces modèles à l’ancienne
Pour ceux-la, on a prévu le SMS il semblerait. Qui a le bon goût de ne pas forcer l'utilisateur a désactiver la notification pour cesser de le déranger, quand il conduit, par exemple.
Non, c'est juste que j'ai perdu mon sens de l'humour ces derniers jours. Il a du se coincer entre les 2 matelas que l'hotel que mon taf a réservé a collé l'un à l'autre pour faire croire a un lit 2 places (et autres problèmes de boulot), va falloir que je le cherche :)
avec un volume de code supérieur au noyau Linux, l'UEFI a nécessairement beaucoup plus de bugs possibles
Je serais curieux de voir le source d'un firmware UEFI? Peut-être qu'il y a une implémentation libre qui te sers de référence ici?
Sinon, j'ai eu a traiter avec UBoot moi. Ben j'aurai préféré UEFI, et pourtant il y a bien moins de lignes de code que pour le noyau je pense (facile a vérifier, c'est libre dans les deux cas).
Quand on n'a jamais vu la lumière des autres firmwares, je peux comprendre l'attrait d'UEFI :)
Je pense qu'à l'heure actuelle j'ai du avoir a traiter avec une 10aine de firmwares UEFI différents, de constructeurs aléatoires. J'ai aussi eu ma part, comme tout le monde ici, de BIOS. Et j'ai eu un cas de UBoot, aussi.
Du coup, avec mon expérience certes limitée (il en existe bien d'autres, j'en suis conscient) UEFI est loin d'être le pire.
Oui, certains été buggués, notamment celui de la CM mano842, mais ce n'était clairement pas des bugs d'UEFI (quand même pas la faute a UEFI si les types sont infoutus de faire une interface non-mensongère!). Et les gens avec qui j'ai traités (c'était pour le taf) étaient d'une compétence douteuse (plusieurs mois pour leur faire comprendre que leur système est buggué, photos et vidéos à l'appui, dans un cas j'ai même du leur envoyer les plans corrects pour faire les câbles dont nous avions besoin et qu'ils étaient censés nous fournir sans efforts de notre part).
Mais bon, pour moi, ce n'est pas UEFI le problème, ici.
UEFI, à la différence des firmwares non normés, permets (en théorie) de garantir un certain nombre de fonctionnalités sans avoir à se palucher la doc, en espérant que l'information soit écrite dedans, ce qui n'est pas garantit. Quand il y a une doc.
Windows 11 le requiert, Windows 10 le suggère cordialement.
Sauf qu'ici on parlait d'une solution technologique, non? Je sais qu'avec l'IA on va finir par pouvoir offusquer les machines (a ne pas confondre avec obfusquer, qui s'applique à leur fonctionnement) mais on n'y est pas encore, si? :)
D'ailleurs au final… c'est pas la faute d'UEFi ça. Il suffit de désactiver le secure boot, qui est certes une fonctionnalité d'UEFI mais le standard n'interdit pas, à ma connaissance, d'implémenter sa désactivation.
Par conséquent, plutôt que taper sur microsoft ou la norme UEFI, ne serait-il pas plus pertinent de taper sur le fournisseur de firmware, que ce journal ne fait même pas semblant de citer?
Parce que les firmware pourris, c'est pas une invention qui découle d'UEFI hein, qui n'a jamais eu de BIOS sur lesquels on galère a faire quoique ce soit?
D'ailleurs, l'histoire de nom de domaine de l'entreprise stocké dans UEFI, c'est encore un problème qui n'est pas la faute ni d'UEFI ni de microsoft, mais bien celui de l'entreprise, non citée, qui n'a pas fait son boulot (ou du presta qui a fait le ménage, pas plus cité). Et s'il est difficile de réinitialiser l'UEFI, c'est, encore, la faute du fournisseur du firmware.
Moi, j'aime bien UEFI.
Grâce à UEFI:
plus besoin de s'emmerder a découper une partition primaire en partitions secondaires (GPT est une techno obligatoire pour supporter UEFI)
plus besoin de se demander si oui ou non la carte réseau supporte boot réseau (BOOTP/HTTP/DHCP/TFTP sont requis pour supporter UEFI)
grub est obligé de montrer qu'il utilise de l'espace disque (ben oui, en partitionnement MSDOS on ne le savait pas, mais grub faisait le gros cochon)
il est possible d'installer le gestionnaire de boot sur une partition a part, facile a modifier
Oui, vraiment, moi j'aime UEFI.
La signature des noyaux et boot loaders? C'est une fonctionnalité dont je n'ai pas besoin perso. L'utilisateur final ici en a-t-il réellement besoin, d'ailleurs?
Si Windows le requiert, alors ça serait bien la leur seul tort pour le coup (et c'est discutable en plus).
Au vu de la mention d'ansible, du pluriel et de l'usage de serveurs, je dirais que le problème que l'OP cherche a résoudre est la gestion de correctifs sur un parc, chose qu'apt-get ou autres ne font pas.
Du coup, oui, ansible est une possibilité, mais personnellement je ne pense pas qu'il s'agisse de la solution la plus efficace, du fait qu'ansible est "sans agent", tout comme rexify ou drist.
Ces solutions sont pratiques dans le cas ou il n'est pas possible d'installer un outil ou si l'on veut éviter de faire tourner un agent H24 (pour des raisons de performances), avec l'inconvénient que si une machine tombe ou est injoignable pour une raison X ou Y, l'indisponibilité ne se résoudra pas toute seule.
Je pense que les solutions a base d'agent, du type cfengine, chef, puppet (flemme de mettre tous les liens) et bien d'autres sont plus pertinentes, mais ça requiert d'installer des logiciels sur les machines cibles ainsi qu'une (ou plusieurs) machine centrales, ce qui implique un impact de performances et une complexité supérieure.
En échange, les machines cibles vont se maintenir "toutes seules", c'est à dire que leur configuration se dirigera vers la configuration voulue, sans intervention manuelle. Bon, évidemment, il reste en pratique à mettre en place le système ainsi qu'a maintenir les configurations.
En terme d'impact sur les performances systèmes, cfengine est le plus léger dans la catégorie des systèmes à agents, étant écrit en C. Il ne nécessite aussi aucune dépendance, et est packagé dans debian, à minima (qui en empaquète d'autres, hein!).
Dans la liste des outils sans agents, rex est en perl, et donc ne nécessite aussi que peu de dépendance, mais celui qui gagne est clairement drist, étant écrit en shell posix, sa portabilité est maximale. Drist est également, et de loin, le plus simple a utiliser.
Bref, il y a pas mal d'outils (open source ET gratuit, j'ai bien l'impression que c'est ce point qui est important pour l'OP :D, bien que par exemple cfengine est poussé par une boîte qui peut vendre du support) pour gérer un parc, chaque solution a ses avantages et inconvénients. Certains outils sont en Ruby, d'autres en python, en C, en bourne shell, en perl… et nécessiterons donc plus ou moins d'efforts en fonction de son confort personnel avec ces différentes techno.
Le commerce, c'est une histoire de comment se faire du beurre sur le dos des producteurs et des utilisateurs, après tout.
C'est une peu une sorte de MitM, au final: le but est de profiter des deux extrémités en se glissant au milieu (non, je n'inclue pas la logistique dans le commerce)
Je me demande, quand même… pourquoi ne pas commencer par bloquer les cookies tiers par défaut?
C'est un réglage que je fais depuis des années sur tous les navigateurs que j'utilise, et les problèmes se sont comptés sur les doigts d'une main (et ça date).
Parce qu'en bloquant les cookies tiers, du coup, le problème serait résolu, non? Et sans usine à gaz…
Justement, je ne considère pas un code simple a comprendre et qui fait quelque chose d'utile efficacement comme étant stupide.
Par contre, j'ai bel et bien vu des bases de code qui se prétendent KISS dont le code fait quelque chose à l'utilité douteuse de manière non efficace.
Je pense ici notamment à la base de code de wesnoth, qui, de mémoire, gérait à un moment la liste des unités avec une foultitude de vector/map/string, sur plusieurs niveaux d'imbrication, avec des struct/class dont la liste des propriétés (variables membres, donc) est longue comme le bras, et pas ordonnée du tout, ce qui implique, entres autres, du padding à la pelle et donc une augmentation de la ram utilisée.
De mémoire, j'ai mesuré récemment que la RSS est d'environ 260 megs au démarrage, pour dépasser les 2 giga quand je suis entrée dans le lobby… de la précédente version stable (debian n'ayant pas l'actuelle stable dans les backports, et moi n'ayant aucune envie d'utiliser un autre gestionnaire de paquets pour ça, ni de compiler).
Du coup (et wesnoth n'est pas le seul cas que j'ai vu, je prend juste comme exemple parce que c'est un très, très bon jeu libre et que pas mal de gens le connaissent), oui, j'ai un peu de mal avec cet acronyme de KISS… peut-être que dans d'autres cas, il est appliqué correctement, mais je n'ai pas encore vu ça.
Il me semble bien que gemini, justement, inclue des outils pour permettre à l'utilisateur de faire des saisies. En tout cas, je suis persuadé d'en avoir utilisé quand je m'y intéressais un peu. Je ne saurais pas retrouver la chose (d'autant que je n'ai pas accès à ma tour ces derniers jours, pour cause de déplacement, ce qui explique la "qualité" du texte précédent, je ne suis vraiment pas à l'aise avec les débilophones).
Considérer que la basile de formulaire est le péché originel du web, je trouve vraiment ça ridicule (et tant pis pour le karma).
Oui. Le form peut utiliser GET et POST. Mais dans tous les cas, le passage d'informations via URI était présent avant.
La seule chose que fait <form> c'est de rendre le truc plus facile, à la fois pour ceux qui savent et pour ceux qui savent pas. C'est bien mon propos: l'ajout de form n'a fait que rendre les choses faciles, mais c'était déjà faisable avant. Et le web n'a pas non plus inventé l'interaction sur l'internet.
l interaction n est pas nee avec le web, irc par exemple est plus vieux.
Meme le web permets d etre interactif sans form: passage de params via uri, cookies…
autant j aime pas vraiment le web, autant j y participe (ici, github…), et la simplicite aide les gens a maitriser, en vrai.
la merde,c est le standard "sables mouvants" qu est le web, pilote par celui qui a la plus grosse. Pas la techno.
encore que… a force de tout inclure tous les 2mois, il faudrait penser a garder un truc implementable from scratch, quitte a virer des elements d une version.
le 2nd de S, c est pour "stupid". c est tres mal choisi, parce que faire simple requiert d'etre smart. les gens stupides ne font pas du simple a maintenir.
je pense que tu confonds variables globales (accessibles hors TU) et variables de module.
La seconde est moins pire, et meme ok en mono-thread.
Mais la solution a trop de variables passees,je crois que c est plutot les "types utilisateur": struct en C. Qui rendent la maintenance de l api plus simple, sans etre la panacee
de memoire, cccc affiche en jaune ce qii depasse 50 lignes de code brut, entres autres.
c est une metrique quej essaie de suivre, mais avec la gestion des erreurs, les logs et autres asserts, 50 se depasse vite.
Apres, le code pour (de-)serialiser est une grosse exception, malheureusement.
Oui, j ai oublie le "entres autres".
Je parie que les conflits git sont moins tordus aussi quand on remplace un gros bloc..
j ai aussi deja pense a utiliser ce type de morcellement, mais clairement il faut un outillage qui masque l'info de bas niveau, ou une trop grosse discipline pour moi.
j y avais pense pour, notamment generer automatiquement le header des classes, maintenu a partir d'un graphe.
Je trouve toujours l idee allechante moi.
Vrai, mais C++ permets aussi de faire à la main.
C'est parfois utile, quand par exemple on veut éviter les réallocations et garder la mémoire "en bloc" (fragmentation mémoire). La STL ne fournit par exemple pas de ring buffer.
On pourrait aussi parler, niveau utilité, de la programmation bare metal (pas d'OS pour gérer la ram).
Certains programmes vont aussi implémenter plusieurs "tas", en fonction de la taille des allocations nécessaires ou de l'espérance de vie, pour des raisons de performances.
On est bien d'accord: ce sont des cas exceptionnels. Mais ils existent, sont pour moi uniquement possibles dans des langages bas-niveau, et le sont en C++. Malgré qu'il fournisse aussi des fonctionnalités de haut niveau (RAII, héritage, exceptions, RTTI. La programmation générique me paraît ni haut, ni bas niveau par contre?).
La STL fournit nombre d'abstractions qu'il est désormais recommandé d'utiliser, sauf si tu as un besoin spécifique bien sûr.
Typiquement, la STL est incapable de gérer le besoin spécifique qui est de gérer des handles, tant que c'est pas des pointeurs.
Descripteurs de fichiers UNIX, ID mémoire opengl, ID de fenêtres WIN32… je pense que certaines API que BDD utilisent aussi des IDs.
Elle est pourtant à mon avis un bon example de fonctionnalités génériques, de haut niveau, puisque le contrôle sur la mémoire est au final assez faible quand on l'utilise, au moindre problème ça balance une exception, et il n'existe à ma connaissance aucun outil capable de vérifier que toutes les exceptions ont été traitées, en C++.
Par contre, le langage lui-même est capable de mieux, notamment pour le debug (non, debug la STL c'est pas génial) ou les systèmes ou les exceptions ne sont pas les bienvenues (pour diverses raisons). Cf eastl.
Maintenant, concernant le C++ et le Go, c'est mécanisme de gestion de mémoire sont bien masqués à l'utilisateur. […] En C++ ce n'est pas toi qui appelle tel ou tel constructeur, ni les destructeurs.
Je vais peut être dire une connerie, mais tu veux dire quoi par "un mécanisme à la defer" pour toi ?
De permettre d'enregistrer des actions qui seront effectuées à la sortie de la fonction, typiquement pour éviter la dose de "goto erreur niveauX: fclose( file );"
Ce que la RAII permets, quoi, mais en moins évolué et sans exceptions (qui ne sont pas appréciées par tout le monde).
# la réponse est à la fin
Posté par freem . En réponse au lien Un Web 100% et uniquement Chromium ?. Évalué à 6.
A la fin de l'article, il cite une des réponses qu'il a eues:
Traduction vite faite, mal faite: ce n'est définitivement pas un objectif, mais ça va arriver de toute façon.
Et ça me paraît clair aussi, depuis longtemps. Tout le monde s'est réjouit de la mort d'IE, je pense que des gens devaient aussi être assez content qu'opera cesse de maintenir son moteur… on a perdu au moins 2 implémentations (et implémenteurs!) alternatives en 10 ans, et aucune nouvelle n'est apparue.
Il ne reste que webkit poussé par Apple (et encore, je ne suis pas sûr qu'ils reversent tout dans webkit, vraiment pas sûr) et gecko. Webkit est la racine de blink (même si depuis le code ne dois plus avoir grand chose en commun, à part l'architecture peut-être), donc on peut en arriver à la conclusion qu'il ne reste vraiment que 2 implémentations hautement conformes, et vu comment la complexité de l'usine à gaz ne cesse d'augmenter, je doute fort que ça ne change.
# galère ce truc
Posté par freem . En réponse au lien Six questions sur FR-Alert, le système d’alerte d’urgence qui arrive sur nos smartphones. Évalué à 5.
A vue de nez ça à l'air bien galère quand même:
Y compris quand les gens sont en train de conduire donc. Devoir manipuler son smartphone au volant, c'est:
La porte ouverte au flood tout ça… Je plains les parisiens, parce qu'avec le traffic qu'ils ont, ça risque de sonner souvent pour cause d'accident de la route.
Bonne portée en plus. Du coup, les autoroutes, campagne ou pas?
Sachant que c'est à la charge des préfectures, suffit d'avoir le bon préfet et ça risque d'être vite fait le carillon…
Sinon, moi je bosse dans des sites indus, et concrètement, le jour ou une sonnerie ne sera pas une sonnerie de test, je suis curieux de voir si elle servira a quelque chose.
Les gens sur un seul site en permanence, eux sauront, certes, mais a vue de nez la masse des travailleurs viens de l'extérieur, et dans mon cas cette année j'ai déjà "visité" 5 sites, chacun avec ses moments de tests différents. Le jour ou ça sonne pour de vrai, je serai incapable de savoir si c'est une sonnerie de test ou pas.
Du coup, si jamais ils s'amusent a flood leurs alertes, ce qui me surprendrais pas vu les délires sécuritaires de partout (qui, ici, considère qu'une alerte orange météo france mérite de s'y attarder? Vigipirate, ça vous parle? Dans un site Seveso, en cas d'attaque terroriste, il faut se cacher… comme ça le mec a le temps de faire péter le pipeline sans être emmerdé!) ça risque bien d'être juste du bruit.
Mais bon, par chance:
Pour ceux-la, on a prévu le SMS il semblerait. Qui a le bon goût de ne pas forcer l'utilisateur a désactiver la notification pour cesser de le déranger, quand il conduit, par exemple.
[^] # Re: euh ça se passait comment jusqu'ici?
Posté par freem . En réponse au lien Vie privée : Mozilla va activer l'isolation des cookies par défaut dans Firefox. Évalué à 2.
Non, c'est juste que j'ai perdu mon sens de l'humour ces derniers jours. Il a du se coincer entre les 2 matelas que l'hotel que mon taf a réservé a collé l'un à l'autre pour faire croire a un lit 2 places (et autres problèmes de boulot), va falloir que je le cherche :)
[^] # Re: Tout est dans la façon de présenter
Posté par freem . En réponse au journal UEFI : y'a pas que les linuxiens qui pleurent…. Évalué à 2.
Je serais curieux de voir le source d'un firmware UEFI? Peut-être qu'il y a une implémentation libre qui te sers de référence ici?
Sinon, j'ai eu a traiter avec UBoot moi. Ben j'aurai préféré UEFI, et pourtant il y a bien moins de lignes de code que pour le noyau je pense (facile a vérifier, c'est libre dans les deux cas).
Je pense qu'à l'heure actuelle j'ai du avoir a traiter avec une 10aine de firmwares UEFI différents, de constructeurs aléatoires. J'ai aussi eu ma part, comme tout le monde ici, de BIOS. Et j'ai eu un cas de UBoot, aussi.
Du coup, avec mon expérience certes limitée (il en existe bien d'autres, j'en suis conscient) UEFI est loin d'être le pire.
Oui, certains été buggués, notamment celui de la CM mano842, mais ce n'était clairement pas des bugs d'UEFI (quand même pas la faute a UEFI si les types sont infoutus de faire une interface non-mensongère!). Et les gens avec qui j'ai traités (c'était pour le taf) étaient d'une compétence douteuse (plusieurs mois pour leur faire comprendre que leur système est buggué, photos et vidéos à l'appui, dans un cas j'ai même du leur envoyer les plans corrects pour faire les câbles dont nous avions besoin et qu'ils étaient censés nous fournir sans efforts de notre part).
Mais bon, pour moi, ce n'est pas UEFI le problème, ici.
UEFI, à la différence des firmwares non normés, permets (en théorie) de garantir un certain nombre de fonctionnalités sans avoir à se palucher la doc, en espérant que l'information soit écrite dedans, ce qui n'est pas garantit. Quand il y a une doc.
Merci de l'info.
[^] # Re: Tout est dans la façon de présenter
Posté par freem . En réponse au journal UEFI : y'a pas que les linuxiens qui pleurent…. Évalué à 3.
Intéressant, je l'ignorais. Comme quoi… (d'un autre côté j'ignore beaucoup de choses sur UEFI, donc c'est pas surprenant)
[^] # Re: Linuxiens unissez vous via une base de donnée UEFI !
Posté par freem . En réponse au journal UEFI : y'a pas que les linuxiens qui pleurent…. Évalué à 4.
Ben, et BSD alors? /me ->[]
[^] # Re: euh ça se passait comment jusqu'ici?
Posté par freem . En réponse au lien Vie privée : Mozilla va activer l'isolation des cookies par défaut dans Firefox. Évalué à 3.
Sauf qu'ici on parlait d'une solution technologique, non? Je sais qu'avec l'IA on va finir par pouvoir offusquer les machines (a ne pas confondre avec obfusquer, qui s'applique à leur fonctionnement) mais on n'y est pas encore, si? :)
[^] # Re: cookie tiers?
Posté par freem . En réponse au lien Vie privée : Mozilla va activer l'isolation des cookies par défaut dans Firefox. Évalué à 2.
hmm… pas souvenir d'être embêté pour payer sans les cookies tiers, pour le coup.
[^] # Re: Non
Posté par freem . En réponse au journal UEFI : y'a pas que les linuxiens qui pleurent…. Évalué à 2.
Et au pire rien n'empêche de se préparer une clé avec syslinux pour booter l'iso, si?
[^] # Re: Tout est dans la façon de présenter
Posté par freem . En réponse au journal UEFI : y'a pas que les linuxiens qui pleurent…. Évalué à 10.
D'ailleurs au final… c'est pas la faute d'UEFi ça. Il suffit de désactiver le secure boot, qui est certes une fonctionnalité d'UEFI mais le standard n'interdit pas, à ma connaissance, d'implémenter sa désactivation.
Par conséquent, plutôt que taper sur microsoft ou la norme UEFI, ne serait-il pas plus pertinent de taper sur le fournisseur de firmware, que ce journal ne fait même pas semblant de citer?
Parce que les firmware pourris, c'est pas une invention qui découle d'UEFI hein, qui n'a jamais eu de BIOS sur lesquels on galère a faire quoique ce soit?
D'ailleurs, l'histoire de nom de domaine de l'entreprise stocké dans UEFI, c'est encore un problème qui n'est pas la faute ni d'UEFI ni de microsoft, mais bien celui de l'entreprise, non citée, qui n'a pas fait son boulot (ou du presta qui a fait le ménage, pas plus cité). Et s'il est difficile de réinitialiser l'UEFI, c'est, encore, la faute du fournisseur du firmware.
Moi, j'aime bien UEFI.
Grâce à UEFI:
Oui, vraiment, moi j'aime UEFI.
La signature des noyaux et boot loaders? C'est une fonctionnalité dont je n'ai pas besoin perso. L'utilisateur final ici en a-t-il réellement besoin, d'ailleurs?
Si Windows le requiert, alors ça serait bien la leur seul tort pour le coup (et c'est discutable en plus).
[^] # Re: apt update + upgrade ?
Posté par freem . En réponse au message gestion des correctifs. Évalué à 5.
Au vu de la mention d'ansible, du pluriel et de l'usage de serveurs, je dirais que le problème que l'OP cherche a résoudre est la gestion de correctifs sur un parc, chose qu'apt-get ou autres ne font pas.
Du coup, oui, ansible est une possibilité, mais personnellement je ne pense pas qu'il s'agisse de la solution la plus efficace, du fait qu'ansible est "sans agent", tout comme rexify ou drist.
Ces solutions sont pratiques dans le cas ou il n'est pas possible d'installer un outil ou si l'on veut éviter de faire tourner un agent H24 (pour des raisons de performances), avec l'inconvénient que si une machine tombe ou est injoignable pour une raison X ou Y, l'indisponibilité ne se résoudra pas toute seule.
Je pense que les solutions a base d'agent, du type cfengine, chef, puppet (flemme de mettre tous les liens) et bien d'autres sont plus pertinentes, mais ça requiert d'installer des logiciels sur les machines cibles ainsi qu'une (ou plusieurs) machine centrales, ce qui implique un impact de performances et une complexité supérieure.
En échange, les machines cibles vont se maintenir "toutes seules", c'est à dire que leur configuration se dirigera vers la configuration voulue, sans intervention manuelle. Bon, évidemment, il reste en pratique à mettre en place le système ainsi qu'a maintenir les configurations.
En terme d'impact sur les performances systèmes, cfengine est le plus léger dans la catégorie des systèmes à agents, étant écrit en C. Il ne nécessite aussi aucune dépendance, et est packagé dans debian, à minima (qui en empaquète d'autres, hein!).
Dans la liste des outils sans agents, rex est en perl, et donc ne nécessite aussi que peu de dépendance, mais celui qui gagne est clairement drist, étant écrit en shell posix, sa portabilité est maximale. Drist est également, et de loin, le plus simple a utiliser.
Bref, il y a pas mal d'outils (open source ET gratuit, j'ai bien l'impression que c'est ce point qui est important pour l'OP :D, bien que par exemple cfengine est poussé par une boîte qui peut vendre du support) pour gérer un parc, chaque solution a ses avantages et inconvénients. Certains outils sont en Ruby, d'autres en python, en C, en bourne shell, en perl… et nécessiterons donc plus ou moins d'efforts en fonction de son confort personnel avec ces différentes techno.
[^] # Re: Ce qui peut se résumer en deux phrases
Posté par freem . En réponse au lien L’arrivée de diplômés d’écoles de commerce à la direction d’entreprises a fait baisser les salaires. Évalué à 10.
Le commerce, c'est une histoire de comment se faire du beurre sur le dos des producteurs et des utilisateurs, après tout.
C'est une peu une sorte de MitM, au final: le but est de profiter des deux extrémités en se glissant au milieu (non, je n'inclue pas la logistique dans le commerce)
[^] # Re: euh ça se passait comment jusqu'ici?
Posté par freem . En réponse au lien Vie privée : Mozilla va activer l'isolation des cookies par défaut dans Firefox. Évalué à 2. Dernière modification le 16 juin 2022 à 13:20.
limité != nul (mais c'est vrai que c'est connoté très négativement)
# cookie tiers?
Posté par freem . En réponse au lien Vie privée : Mozilla va activer l'isolation des cookies par défaut dans Firefox. Évalué à 3.
Je me demande, quand même… pourquoi ne pas commencer par bloquer les cookies tiers par défaut?
C'est un réglage que je fais depuis des années sur tous les navigateurs que j'utilise, et les problèmes se sont comptés sur les doigts d'une main (et ça date).
Parce qu'en bloquant les cookies tiers, du coup, le problème serait résolu, non? Et sans usine à gaz…
[^] # Re: Bof
Posté par freem . En réponse au journal Software architecture considered harmful. Évalué à 2.
Justement, je ne considère pas un code simple a comprendre et qui fait quelque chose d'utile efficacement comme étant stupide.
Par contre, j'ai bel et bien vu des bases de code qui se prétendent KISS dont le code fait quelque chose à l'utilité douteuse de manière non efficace.
Je pense ici notamment à la base de code de wesnoth, qui, de mémoire, gérait à un moment la liste des unités avec une foultitude de vector/map/string, sur plusieurs niveaux d'imbrication, avec des struct/class dont la liste des propriétés (variables membres, donc) est longue comme le bras, et pas ordonnée du tout, ce qui implique, entres autres, du padding à la pelle et donc une augmentation de la ram utilisée.
De mémoire, j'ai mesuré récemment que la RSS est d'environ 260 megs au démarrage, pour dépasser les 2 giga quand je suis entrée dans le lobby… de la précédente version stable (debian n'ayant pas l'actuelle stable dans les backports, et moi n'ayant aucune envie d'utiliser un autre gestionnaire de paquets pour ça, ni de compiler).
Du coup (et wesnoth n'est pas le seul cas que j'ai vu, je prend juste comme exemple parce que c'est un très, très bon jeu libre et que pas mal de gens le connaissent), oui, j'ai un peu de mal avec cet acronyme de KISS… peut-être que dans d'autres cas, il est appliqué correctement, mais je n'ai pas encore vu ça.
[^] # Re: ridicule
Posté par freem . En réponse au lien The ‘Form’ Element Created the Modern Web. Was It a Big Mistake?. Évalué à 2.
Il me semble bien que gemini, justement, inclue des outils pour permettre à l'utilisateur de faire des saisies. En tout cas, je suis persuadé d'en avoir utilisé quand je m'y intéressais un peu. Je ne saurais pas retrouver la chose (d'autant que je n'ai pas accès à ma tour ces derniers jours, pour cause de déplacement, ce qui explique la "qualité" du texte précédent, je ne suis vraiment pas à l'aise avec les débilophones).
Considérer que la basile de formulaire est le péché originel du web, je trouve vraiment ça ridicule (et tant pis pour le karma).
[^] # Re: ridicule
Posté par freem . En réponse au lien The ‘Form’ Element Created the Modern Web. Was It a Big Mistake?. Évalué à 2.
Oui. Le form peut utiliser GET et POST. Mais dans tous les cas, le passage d'informations via URI était présent avant.
La seule chose que fait
<form>
c'est de rendre le truc plus facile, à la fois pour ceux qui savent et pour ceux qui savent pas. C'est bien mon propos: l'ajout de form n'a fait que rendre les choses faciles, mais c'était déjà faisable avant. Et le web n'a pas non plus inventé l'interaction sur l'internet.# ridicule
Posté par freem . En réponse au lien The ‘Form’ Element Created the Modern Web. Was It a Big Mistake?. Évalué à -1.
l interaction n est pas nee avec le web, irc par exemple est plus vieux.
Meme le web permets d etre interactif sans form: passage de params via uri, cookies…
autant j aime pas vraiment le web, autant j y participe (ici, github…), et la simplicite aide les gens a maitriser, en vrai.
la merde,c est le standard "sables mouvants" qu est le web, pilote par celui qui a la plus grosse. Pas la techno.
encore que… a force de tout inclure tous les 2mois, il faudrait penser a garder un truc implementable from scratch, quitte a virer des elements d une version.
[^] # Re: Bof
Posté par freem . En réponse au journal Software architecture considered harmful. Évalué à 2.
le 2nd de S, c est pour "stupid". c est tres mal choisi, parce que faire simple requiert d'etre smart. les gens stupides ne font pas du simple a maintenir.
[^] # Re: et les fonctions
Posté par freem . En réponse au journal Software architecture considered harmful. Évalué à 2.
je pense que tu confonds variables globales (accessibles hors TU) et variables de module.
La seconde est moins pire, et meme ok en mono-thread.
Mais la solution a trop de variables passees,je crois que c est plutot les "types utilisateur": struct en C. Qui rendent la maintenance de l api plus simple, sans etre la panacee
[^] # Re: et les fonctions
Posté par freem . En réponse au journal Software architecture considered harmful. Évalué à 2.
de memoire, cccc affiche en jaune ce qii depasse 50 lignes de code brut, entres autres.
c est une metrique quej essaie de suivre, mais avec la gestion des erreurs, les logs et autres asserts, 50 se depasse vite.
Apres, le code pour (de-)serialiser est une grosse exception, malheureusement.
[^] # Re: tss tss...
Posté par freem . En réponse au journal Software architecture considered harmful. Évalué à 2.
Oui, j ai oublie le "entres autres".
Je parie que les conflits git sont moins tordus aussi quand on remplace un gros bloc..
j ai aussi deja pense a utiliser ce type de morcellement, mais clairement il faut un outillage qui masque l'info de bas niveau, ou une trop grosse discipline pour moi.
j y avais pense pour, notamment generer automatiquement le header des classes, maintenu a partir d'un graphe.
Je trouve toujours l idee allechante moi.
[^] # Re: C++, haut niveau ?
Posté par freem . En réponse au journal Écrire un jeu en Rust presque de zéro. Évalué à 4.
Vrai, mais C++ permets aussi de faire à la main.
C'est parfois utile, quand par exemple on veut éviter les réallocations et garder la mémoire "en bloc" (fragmentation mémoire). La STL ne fournit par exemple pas de ring buffer.
On pourrait aussi parler, niveau utilité, de la programmation bare metal (pas d'OS pour gérer la ram).
Certains programmes vont aussi implémenter plusieurs "tas", en fonction de la taille des allocations nécessaires ou de l'espérance de vie, pour des raisons de performances.
On est bien d'accord: ce sont des cas exceptionnels. Mais ils existent, sont pour moi uniquement possibles dans des langages bas-niveau, et le sont en C++. Malgré qu'il fournisse aussi des fonctionnalités de haut niveau (RAII, héritage, exceptions, RTTI. La programmation générique me paraît ni haut, ni bas niveau par contre?).
Typiquement, la STL est incapable de gérer le besoin spécifique qui est de gérer des handles, tant que c'est pas des pointeurs.
Descripteurs de fichiers UNIX, ID mémoire opengl, ID de fenêtres WIN32… je pense que certaines API que BDD utilisent aussi des IDs.
Elle est pourtant à mon avis un bon example de fonctionnalités génériques, de haut niveau, puisque le contrôle sur la mémoire est au final assez faible quand on l'utilise, au moindre problème ça balance une exception, et il n'existe à ma connaissance aucun outil capable de vérifier que toutes les exceptions ont été traitées, en C++.
Par contre, le langage lui-même est capable de mieux, notamment pour le debug (non, debug la STL c'est pas génial) ou les systèmes ou les exceptions ne sont pas les bienvenues (pour diverses raisons). Cf eastl.
[^] # Re: C++, haut niveau ?
Posté par freem . En réponse au journal Écrire un jeu en Rust presque de zéro. Évalué à 3.
On évite, mais on peut: placement new.
[^] # Re: C++, haut niveau ?
Posté par freem . En réponse au journal Écrire un jeu en Rust presque de zéro. Évalué à 2.
De permettre d'enregistrer des actions qui seront effectuées à la sortie de la fonction, typiquement pour éviter la dose de "goto erreur niveauX: fclose( file );"
Ce que la RAII permets, quoi, mais en moins évolué et sans exceptions (qui ne sont pas appréciées par tout le monde).