HN Digest
Briefing personnel.

Lire vite.
Garder l'essentiel.

Les meilleurs longs formats de Hacker News, relus plus calmement.

11707 articles Page 887/1171 Sans filtre

Productive Procrastination

L'auteur décrit une forme de procrastination où il reste productif mais préfère travailler sur des projets récents plutôt que sur les tâches prioritaires, illustrée par le fait d'avoir publié une vidéo récente au lieu de terminer des montages plus anciens. En s'appuyant sur la matrice de productivité de Casey Neistat, il note qu'il existe une catégorie non couverte — la « procrastination productive » — où l'on accomplit des tâches utiles mais pas celles qui sont réellement importantes. La littérature cognitive explique ce comportement par un conflit entre l'amygdale, qui répond aux émotions négatives et incite à l'évitement, et le cortex préfrontal, responsable du contrôle des impulsions et de la planification. Les études sur la récompense montrent que la nouveauté active davantage le système dopaminergique, et ses propres données suggèrent que sa productivité diminue avec l'écart entre enregistrement et montage tandis que les projets récents ont un rendement supérieur. Pour y remédier il propose de rendre les anciens projets « nouveaux » par des techniques différentes, de nommer ses émotions, de se pardonner et d'instaurer des habitudes et des plans concrets pour diminuer la culpabilité et faciliter le démarrage.

How much linear memory access is enough?

L'auteur mesure combien doivent être grosses les blocs contigus de mémoire pour que les sauts entre blocs n'impactent plus les performances, car la mise en page et le pattern d'accès mémoire sont critiques en calcul haute performance. L'expérience place des blocs contigus de différentes tailles dans une grande mémoire de backing avec layout aléatoire, clobbere le cache avant chaque essai, répète les exécutions et utilise la médiane pour réduire le bruit de mesure. Résultat principal : des blocs de 1 Mo suffisent pour la plupart des charges parcourant linéairement les données, 128 ko sont généralement suffisants dès qu'on est à environ 1 cycle par octet et 4 ko suffisent si le traitement coûte environ 10 cycles par octet. Selon le noyau testé, les seuils diffèrent : le sommé SIMD (simd_sum) atteint son pic vers 1 Mo, le noyau scalaire (scalar_stats) vers 128 ko et le noyau lourd en trigonométrie (heavy_sin) est quasi optimal dès quelques kilo‑octets. Ces conclusions valent pour des parcours linéaires en lecture sans coûts par bloc additionnels et pour exécutions mono‑threadées, donc elles peuvent changer si on alloue à la volée, si on effectue des écritures, du striding ou du multi‑threading ; néanmoins, les tailles de bloc nécessaires pour des performances maximales sont souvent bien plus petites que ce qu'on pourrait attendre.

Brocards for Vulnerability Triage

L'auteur, qui fait du triage de vulnérabilités sur des projets open source, compile des brocards pour évaluer la légitimité des signalements. Un signalement sans modèle de menace explicite ou cohérent peut être écarté car il ne montre pas comment un attaquant exploiterait le comportement décrit. Un rapport n'est pas une vulnérabilité si l'exploitation requiert des capacités plus puissantes que celles que la faille présumée fournirait, par exemple un MiTM actif ou l'exécution de code arbitraire préalable. Sont également écartables les comportements qui n'apparaissent pas dans l'usage réel, qui violent des invariants dont le programmeur est responsable, ou qui résultent de l'application correcte d'une norme plutôt que d'une mauvaise implémentation. Enfin, il recommande de rejeter les correctifs dont les conséquences sont pires que la faille et rappelle que l'existence d'un signalement ou d'un identifiant comme un CVE n'est ni nécessaire ni suffisante pour établir une vulnérabilité.

High-Level Rust: Getting 80% of the Benefits with 20% of the Pain

L'auteur affirme qu'il n'existe pas de langage parfait et qu'il a alterné entre F#, TypeScript et C# sans trouver un compromis satisfaisant. Il décrit F# comme possédant d'excellents types mais un écosystème restreint, TypeScript comme omniprésent mais avec des types peu fiables, et C# comme solide mais verbeux et sans unions natives. Rust est présenté comme un candidat sérieux pour ses types expressifs, ses performances proches du C et son écosystème en croissance, mais il est pénalisé par une courbe d'apprentissage raide et une moindre vélocité de développement. La méthode proposée consiste à traiter Rust en langage de haut niveau via une modélisation de domaine centrée sur les types, une logique fonctionnelle immuable et des services DDD utilisant Arc et des clones généreux pour réduire les contraintes liées au borrow checker, en acceptant une perte de performance modérée et la surveillance des coûts de clonage. L'auteur juge cette approche adaptée aux API web et applications orientées logique métier mais non aux chemins critiques ou systèmes très performants, et il expérimente l'outil LightClone pour aider à maîtriser les clones pendant sa phase d'exploration.

How Passive Radar Works

Le radar passif fonctionne sans émetteur en écoutant des émissions existantes comme la FM ou la télévision pour détecter les échos réfléchis par des objets. Un récepteur passif compare le signal direct du diffuseur et l'écho réfléchi pour extraire le décalage Doppler (vitesse) et le retard temporel (distance relative). Parce que l'émetteur et le récepteur sont séparés, un même retard correspond à une ellipse dont les foyers sont l'émetteur et le récepteur, et la position d'un objet se déduit de l'intersection de plusieurs ellipses. Les avantages incluent l'absence d'émission, un coût réduit, une mise en œuvre légale et discrète, et une évolutivité par ajout de récepteurs, tandis que les inconvénients comprennent la dépendance aux émetteurs tiers, une précision et une résolution moindres et des traitements du signal complexes. L'intérêt croissant pour le radar passif tient à son accessibilité technique et réglementaire grâce au matériel abordable et à l'absence de licence d'émission.

Layoff Thinking

LinkedIn regorge d'histoires de licenciements, et un post récent a incité l'auteur à s'interroger sur la réaction viscérale que provoque la perte d'emploi. Le post cité soutient que, dans le capitalisme, de nombreuses personnes conditionnent leur valeur à leur capacité à gagner de l'argent et externalisent ainsi leur estime personnelle. Dans les sociétés occidentales, l'identité est souvent définie par le travail, comme l'illustre la question habituelle «Que faites‑vous?» posée pour se présenter et situer autrui. Les licenciements peuvent donc ébranler profondément le sens de soi, et l'auteur conseille de se recentrer sur des aspects non professionnels de l'identité (loisirs, famille, passions) pour réduire cette vulnérabilité. L'auteur rapporte qu'une «sabbatique involontaire» de trois ans l'a aidé à garder la santé mentale et à retrouver de l'espoir.

Phone Trips

Il se présente sous le pseudonyme Mark Bernay et raconte qu'il effectuait il y a environ trente-cinq ans des excursions pour jouer avec des téléphones publics. Il emportait un enregistreur à bobines Craig 212 pour capturer les bruits des communications et commentait les enregistrements pour ses amis. Il a arrêté ces excursions non parce qu'il a mûri, mais parce que les téléphones étaient devenus uniformes et ennuyeux. Il explique avoir commencé adolescent à Los Angeles, avoir constaté des différences de sonorité entre opérateurs, visité des centraux téléphoniques, puis s'être installé à Seattle en 1968 où de nombreuses petites villes possédaient des sociétés téléphoniques indépendantes et des équipements variés. Pour enregistrer, il plaçait le microphone contre les écouteurs des cabines en évitant les bobines de captation à cause du ronron des lampes, il ne possède pas de photos de ses propres voyages, la photo fournie par un ami montre des personnes qui n'ont pas participé aux enregistrements et l'homme au téléphone est une figure connue.