Nyctography: A substituton cypher by Lewis Carroll
Résumé indisponible pour cet article.
Les meilleurs longs formats de Hacker News, relus plus calmement.
Résumé indisponible pour cet article.
L'équipe a développé un compilateur quantique appelé Catalyst pour PennyLane afin d'optimiser des workflows hybrides quantiques-classiques à grande échelle en utilisant MLIR. Ils ont choisi JAX pour tracer le code Python (y compris NumPy et SciPy) et l'abaisser vers MLIR, puis ont intercepté cette représentation pour la transformer directement en dialectes MLIR standards et en LLVM, contournant ainsi l'exécution XLA. Le pipeline prend en charge la différentiation inverse via Enzyme pour le code classique compilé et utilise des passes MLIR personnalisées pour générer les gradients quantiques, tout en supportant le contrôle Python natif et les tableaux à formes dynamiques. Cette approche permet de produire des binaires AOT autonomes sans runtime ML lourd, d'améliorer le support des tailles dynamiques, de cibler du matériel embarqué et d'insérer des dialectes et passes MLIR personnalisés. Les auteurs soulignent que la solution ne concurrence pas XLA pour l'entraînement massif de modèles standards, mais qu'elle offre des avantages pour le calcul quantique, le matériel sur mesure et les déploiements edge.
Bien que les flux RSS soient encore largement utilisés, leur adoption a souffert parce que plusieurs grandes entreprises technologiques, et en particulier Google, ont rendu leur usage plus difficile. Chrome a supprimé sans explication le bouton d'abonnement RSS et a fait disparaître puis rétablir une extension RSS, ce qui a diminué la confiance des utilisateurs. Après l'acquisition de FeedBurner en 2007, Google a fermé des API en 2012 et supprimé des services essentiels en 2022, dégradant les fonctionnalités et les abonnements email pour de nombreux éditeurs. Google a aussi fermé Google Reader en 2013, retiré puis partiellement rétabli les flux RSS de Google Alerts et supprimé le support RSS de Google News en 2017, forçant les utilisateurs à chercher des alternatives. L'article conclut que le comportement récurrent d'intégrer puis d'abandonner le RSS nuit à l'ouverture du web et invite Google à soutenir et maintenir durablement ces fonctionnalités pour préserver la liberté numérique.
QSYRUPWD est une API IBM i qui renvoie, à des appelants autorisés, des données liées aux mots de passe sous forme chiffrée pour des usages d'administration tels que synchronisation, migration et réplication. L'auteur a constaté qu'avec la valeur système QPWDLVL réglée à 2–4 la sortie de QSYRUPWD ne correspondait pas aux formats IBM i pris en charge par John the Ripper pour les anciens vérificateurs, ce qui a motivé une analyse approfondie. En combinant un petit programme CL, la collecte d'un trace d'appels (STRTRC), des dumps et de la désassemblage via System Service Tools, puis des points d'arrêt artificiels sur les appels SCV 10 (fonction CIPHER), l'analyse a révélé une chaîne de transformations cryptographiques (SHA‑1, MD5, opérations Rijndael/AES non standard et réordonnancement d'octets) orchestrées par des appels MI. En reconstituant l'ordre des opérations et en inférant l'algorithme qui fabrique une clé de 32 octets à partir du nom d'utilisateur en EBCDIC et de la valeur DES sur 8 octets quand elle existe, l'auteur a pu déchiffrer les blocs retournés par QSYRUPWD et extraire les valeurs DES, SHA‑1 et NTLM exploitables pour du craquage hors ligne, y compris sur des systèmes QPWDLVL = 4 où les champs hérités ont été annulés. L'extraction nécessite les autorités *ALLOBJ et *SECADM mais permet néanmoins à un administrateur privilégié d'obtenir du matériel de vérification convertible en hashes craquables hors ligne, de sorte que la recommandation est de limiter et surveiller strictement ces profils, d'empêcher l'adoption d'autorité lorsque possible et d'envisager une modification côté IBM pour empêcher l'export de données réutilisables.
L'auteur soutient qu'Atom est techniquement supérieur à RSS et que la migration aurait dû se faire depuis longtemps. Malgré cela, de nombreux éditeurs continuent à produire et à choisir RSS par ignorance, habitude ou indifférence, et la plupart des lecteurs supportent Atom. Certaines différences paraissent mineures mais posent des problèmes concrets : RSS ne définit pas clairement les sémantiques d'encodage pour les titres et le contenu, ce qui rend incertain l'usage de caractères comme < ou & ou de balises dans les titres. Atom propose des text constructs permettant de spécifier si une valeur est du texte, du HTML encodé par entités ou du HTML encodé en XML, ce qui rend non ambiguë la gestion de titres balisés et la distinction résumé/entrée complète. Les podcasts sont l'exception pratique : des acteurs majeurs, notamment Apple au début, n'ont supporté que RSS, ce qui a figé des hacks et renforcé la dominance de RSS pour les flux de podcasts.
Les LSE ne sont pas indépendants et ont tendance à se produire en grappes spatialement et temporellement, ce qui complique l'évaluation du risque de corruption partagée entre disques. Il est impossible de reconstruire la probabilité conjointe P[S] d'un ensemble de secteurs corrompus à partir des seules probabilités marginales P[s] et conditionnelles P[s1|s2], donc l'auteur adopte une approche approximative et justifiable. L'approche retenue utilise une probabilité a priori empirique tenant compte des corrélations observées, traite les événements de secteurs défaillants sur les autres disques comme indépendants pour obtenir une estimation conservatrice, et augmente la granularité à des blocs de 16 KiB pour coller au format des blocs btrfs. Le nouveau PMF sur blocs 16 KiB est approximativement 81 % pour un seul secteur défaillant, 15 % pour 2–3 et 4 % pour 4 ou plus, et la probabilité qu'au moins un des k−1 autres disques partage l'un des m LSE est approximée par 1−(1−p^{k−1})^{m} en supposant l'indépendance. Enfin la probabilité qu'un disque ait une LSE sur un secteur est approximée par le produit du taux empirique d'LSE, du temps de rebuild et du rapport taille du secteur / taille du disque, et chaque lecture lors du rebuild est traitée comme une épreuve de Bernoulli.
Morph conçoit l'infrastructure d'inférence derrière les modèles open les plus rapides et recrute un ingénieur performance pour accélérer, réduire le coût et fiabiliser l'ensemble du système. Le rôle consiste à identifier l'écart entre les performances matérielles théoriques et celles en production et à tracer les régressions de latence et de débit depuis la couche API jusqu'aux noyaux individuels. Vous optimiserez le batching, l'ordonnancement, le routage, la quantification et l'exécution distribuée, et vous développerez des benchmarks et de l'observabilité pour rendre les goulets d'étranglement évidents tout en validant la qualité des modèles. Le candidat idéal a de l'expérience sur des systèmes de production complexes, comprend les performances GPU, la bande passante mémoire et les collectives, maîtrise Python et sait transformer des profils en décisions d'ingénierie tout en équilibrant tokens par seconde, tokens par dollar et exactitude. Vous travaillerez directement avec les fondateurs au sein d'une petite équipe disposant d'une puissance de calcul importante et d'un impact immédiat en production.
Le site fournit des tarifs en temps réel pour plus de 232 modèles et des calculateurs qui estiment le coût mensuel d'un chatbot, d'un agent ou d'une API. Des calculateurs dédiés simulent des conversations avec historique et cache, évaluent des agents multi‑étapes, chiffrent les architectures RAG, la voix (STT+LLM+TTS), la location GPU et le prix par image, et incluent un compteur de tokens côté client. Les guides proposent des stratégies d'optimisation comme le prompt caching (jusqu'à −90% sur les entrées) et le Batch API (environ −50% sur l'ensemble) pour réduire substantiellement les coûts. Les fournisseurs facturent par token avec des tarifs distincts pour l'entrée et la sortie, la sortie étant généralement 3–5× plus chère, ce qui fait qu'un modèle affiché à 5/25 $/M tokens coûte 5 $ pour un million de tokens envoyés et 25 $ pour un million générés. Les calculateurs prennent en compte le caching et les remises par lot, ce qui explique pourquoi leurs estimations sont souvent beaucoup plus précises que celles d'articles qui omettent ces rabais.
Résumé indisponible pour cet article.
L'auteur distingue quatre échelles de temps différentes pour le développement et le déploiement des technologies et souligne que leur confusion conduit à des prévisions erronées. Les nouvelles idées de recherche prennent généralement dix à vingt ans, parfois plusieurs décennies, pour aboutir à des démonstrations de laboratoire robustes, comme le montre l'évolution des modèles neuronaux jusqu'aux réseaux profonds et aux LLMs. Les cycles de battage médiatique peuvent propulser une technologie en quelques mois dans la presse et la publicité (agents, blockchain, métavers), mais cet engouement surestime souvent l'impact réel et s'estompe ensuite. La mise en œuvre à grande échelle requiert souvent vingt ans ou plus et implique des défis majeurs d'adoption, de chaînes d'approvisionnement et de support client, comme l'illustre l'histoire d'Unix/Linux et le déploiement limité des voitures autonomes. La transformation réelle de l'économie mondiale par une technologie demande des décennies, fréquemment plus de cinquante ans, de sorte que promettre une révolution économique en quelques années est irréaliste.