aiolos a écrit 1198 commentaires

Ou qu’elles s’en servent comme garantie pour un prêt en vraie monnaie…

LSP ?

403 c'est une erreur HTTP qui veut dire que tu n'es pas autorisé à accéder l'URL, et te ré-authentifier ne changera pas ça, rien à voir avec le DNS.

Par contre, je n'ai aucune idée de comment résoudre ton soucis, mais peut-être que cette indication t'aidera à aller un peu plus loin dans tes recherches…

Je m’insurge, la communauté est aussi pleine de pinailleurs bienveillants ! ;)

Franchement, tu interpoles beaucoup sur le propos. Ils expliquent uniquement pourquoi ce groupe de libraires indépendants ne mettront plus en avant, voir refuserons de vendre, des livres du groupe Hachette.

Si ils voulaient vraiment "désarmer l'empire Bolloré" (et Amazon), ils feraient une offre alternative qui vous intéresserait

Mais ils proposent justement une alternative : le monde les librairies et des éditeurs indépendants, qui est déjà présent sur tout le territoire en France. C'est ce qui leur permet justement d'avoir ce choix sur les livres qu'ils proposent et mettent en avant !

Que cette alternative ne te plaise pas et/ou ne te suffise pas est une chose, mais elle est là. Et moi, elle me satisfait. Et si j'en crois l'état de l'industrie en livre en France, on est beaucoup dans ce cas.

Quelqu’un à des retours d’expérience sur Openshift ?

Le problème principal à mon avis, c'est qu'on s'en fout de ses compétences, au gamin. Il est là pour observer, voir à quoi ça ressemble aller au travail, et éventuellement si ça peut le tenter. Qu'il sache ou aime faire de maths ou de l'histoire géo, globalement on s'en tape un peu, non ? Il y tant d'enfants qui veulent venir faire leur stage de 3e dans votre entreprise que vous êtes obligés de trier ?

J'ai le même et au bout d'une semaine, je n'ai plus d'usb et d'ethernet, par contre l'affichage marche très bien. Peut-être la faute à pas de chance…

Les plus connus supportent, en plus du stockage des secrets, la génération des OTPs par TOTP et HOTP. C'est par exemple le cas de KeepassXC et de Bitwarden, pour ne citer que ces deux là.

Tout ce que tu dis est faisable tout en utilisant un gestionnaire de dépendance avancé et plus ou moins centralisé, pour peu que tu utilise un repo d’artefacts dans ton infra. C’est ce qui se fait couramment depuis longtemps dans le monde java avec artifactory, et plus récemment avec ce que propose gitlab.

Mettre tes dépendances en dur dans ton repo git ne solutionne en rien les gens qui mettent n’importe quelle depedance dans leur soft, mais complique beaucoup leur suivi. En pratique, plus ton process d’update de tes dépendances est manuel, moins leur mise à jour est effectuée régulièrement. Sans parler du suivi de leur recensement.

Pour moi, le problème de base, c’est surtout le nombre énorme de dépendances triviales qui sont dans ces repos qui rendent impossible leur suivi effectif, surtout si tu rajoutes de la transitivité et les versions multiples que ca ramène. Et aussi, les pratiques qui consistent à ne pas se soucier des dépendances qu’on importe.

Et là éventuellement, il y a un avantage pour la gestion à la main : c’est tellement chiant et impactant que tu va pas être tenté de mettre un truc pour trois lignes. Maintenir le code sera largemet moins coûteux… mais c’est aussi le cas pour ceux qui ont importé is-even.

Je dirais bien que normalement on ne devrait pas avoir à en faire des tartines, mais je me retiendrai par respect pour mon interlocuteur.

Je ne suis pas sûr que devoir aller vérifier quelle version de telle librairie disponible sur github et mise à la main dans le projet doit beaucoup plus efficace en terme de sécurité…

Et les constructeurs de smartphones n'ont aucune volonté d'y remédier, ni apparemment les vendeurs de SoC (enfin, il me semble qu'il y a des balbutiements…)

Et d'ailleurs, sur x86, cette standardisation ça n'a jamais été la volonté des vendeurs de matériel ; il a fallu qu'un concurrent fasse le reverse engineering du BIOS pour que cette standardisation de fait débute…

A mon avis, tu aurais vraiment intérêt à ne changer qu'un seul paramètre à la fois…

En vrai, si le test est passé avec brio avec l'usage d'un LLM, c'est soit qu'il ne sert pas à détecter grand chose, soit que le travail qu'on va te demander va être chiant comme la mort… Dans les deux cas, ce n'est pas très bon signe.

Après, c'est peut-être mon point de vue de senior, qui n'a pas eu trop de difficulté à trouver un travail d'archi et qui a pu se permettre d'envoyer péter à peu prêt quiconque envoyait un test technique de ce genre… Et du point de vue du recruteur, je n'ai jamais vu de test technique qui m'ait appris beaucoup plus de chose que ce que j'avais déjà perçu après un premier entretien technique.
En gros, tu vas trouver quatre profils :
- le junior/reprise d'emploi : ça fait le taf, mais c'est pas très propre ;
- le gars qui sort de 2 ans d'ESN/Software factory : c'est carré, c'est joli, c'est polissé, mais c'est sans surprise ;
- le senior qui a torché le truc rapidement, et qui va te faire des petits trucs, sympa à avoir (conteneur docker, CI/CD, Swagger, etc.) ;
- le nul : il a rien fait ou de la merde.
Donc en fait, tout ça, tu peux le détecter en discutant autour d'un code à toi, voir un extrait du code du produit sur lequel le candidat devra bosser, amha, et tu ne demandes pas à des gens qui ne travaillent pas pour toi de prendre du temps à travailler pour un résultat hasardeux. Et comme en plus, tu ne peux pas vérifier l'origine réelle du code (aide d'un pote, ChatGPT et consorts, etc.), tu devra vérifier dans tous les cas si le gars en face comprend le code qu'il t'a envoyé.

D'ailleurs la seule fois où j'ai cédé et fait l'exercice, l'entretien a bifurqué sur autre chose après 30 secondes de discussion sur l'exercice qui m'avait pris un peu plus de 2h à faire, et pour lequel j'avais appris à me servir d'un framework connu que je n'avais jamais eu à utiliser…

Donc, pour conclure : en l’absence d'autre motivation (produit intéressant, équipe sympa, stack technique motivante), si t'es pressé de trouver et que le marché n'est pas trop bouché chez toi, tu prends le taf, et si ça te plait pas, tu commences tout de suite à chercher autre chose. Si tu peux te permettre d'attendre, tu pourras sans doute trouver mieux.

il semble relativement facile de venir contourner quelques limitations (ex : 10 signature request emails per month).

Cette limitation est uniquement sur la version cloud, pas sur la version on-premise, sans doute pour cette raison…

Donc le problème viens très probablement du WiFi chez toi. Deux causes possibles :
- le matériel, c'est à dire la box, dont les WiFi sont souvent pas super ;
- l'environnement (interférences, bande de fréquence surchargées, etc.).

Si tu peux trouver un routeur WiFi à te faire prêter, tu pourras peut-être éliminer ou confirmer le matériel. Si, configuré avec les mêmes paramètres, tu as les mêmes soucis avec le nouveau routeur, c'est l'environnement, sinon, c'est le matériel et tu as ta solution (changer le matos ou acheter un routeur WiFi).

Perso, le gros no-go de ce genre de grille tarifaire, c'est les options relatives au SSO en version premium. C'est tellement mesquin comme façon de faire ; c'est le rendre quasi-inutilisable en entreprise, et limite irresponsable tant ça contribue à de mauvaises pratiques.

Oui, d'autant plus qu'ils développeraient un plugin pour Firefox (en Rust) : https://linuxfr.org/users/antistress/liens/google-pourrait-developper-un-decodeur-jpeg-xl-en-rust-pour-firefox-phoronix

Oui, plus que le développement de ce type de fishing, qui effectivement existe déjà, c'est leur mise en uvre qui est coûteuse. Notamment parce que c'est des attaques à faire de façon synchrone…

Il n'a jamais été dit que les deux facteurs ne devaient pas se trouver au même endroit pour l'authentification forte. Uniquement qu'il fallait 2 facteurs parmi les trois suivants :
- ce que sais (code) ;
- ce que je possède (carte/téléphone/etc.) ;
- ce que je suis (biométrie).

Les cartes à puce, par exemple les cartes bancaires, proposent directement deux facteurs sur un seul support : ce que je possède (la carte, via la clef qui y est stockée) et ce que je sais (le code PIN). C'est pourtant considéré comme une solution d'authentification forte.

Dans le cas d'une appli bancaire sur ton téléphone, tu peux avoir deux facteurs : ce que je possède via la clef spécifique à l'instance de l'appli et ce que je suis (via la biométrie du téléphone) ou ce que je connais (via un mot de passe d'appli).

Pour les TOTPs, le but était d'ajouter au mot de passe (ce que je sais), une preuve de possession d'un autre appareil (qui stocke la clef du TOTP), mais depuis le temps, cette idée s'est galvaudée et on lit tout et n'importe quoi. C'est pour ça que FIDO est passé d'un protocole qui permettait et l'authentification et le second facteur à un seul protocole de 2FA, proche de celui proposé pour l'authentification en première instance : la sécurité perçue est plus grande, alors même que la clef FIDO pourrait suffire à elle seule.

Il n'en reste pas moins que les solutions de 2FA sont aujourd'hui la solution la plus simple pour se prémunir du fishing, du moins tant que ce sera plus rentable d'attaquer les gens non équipés que de développer un fishing qui attaque directement le 2FA…

On n'est jamais aussi bien servi que par soi-même :)

En matière de sécurité, ça reste à prouver, imho…

on oublie parfois qu'on est face à un noyau Linux, et qu'en tant que geeks, on a la responsabilité de s'impliquer dans l'évolution de ces appareils.

Excuse moi, mais je pense que j'ai la responsabilité de que dalle dans ce contexte. Avec ce résonnement, j'ai la responsabilité de m'impliquer dans l'évolution de la Freebox, la TiVo et les voitures Tesla ! Au mieux, en tant que sachant, j'en ai la possibilité, mais ce n'est sûrement pas une responsabilité !

Ici, on se focalise souvent sur Android = GAFAM, mais il ne faut pas oublier qu'Android permet de se détacher de cet écosystème grâce aux contributions de la communauté open source.

Je pense qu'ici, on est beaucoup à fonctionner sur des Android dégafamisé. Je pense même qu'on est un certain nombre à avoir travaillé sur du Android, au niveau matériel ou plus haut niveau, avec ou sans lien avec Google.

Pour ressouder le port USB-C, il faudrait de toute façon retirer la batterie.

Mais pourquoi donc ?

C’est surtout que depuis 1978, en France, la loi informatique et liberté interdit de réutiliser les identifiants entre services. Ce qui fait qu’on ne peut pas utiliser le numéro INSEE pour les impôts, par exemple.

Merci pour la précision, je n'avais pas vu cet aspect, je voyais ça comme des sondes classiques qui se pincent sur les pattes, j'arrivais pas à piger la révolution…