Mentions

From the Zoo to the BULLPEN: Sample-Efficient LLM Profiling via Multi-Channel Model Embeddings Russell Ro, Qiming Cui, Reza Abbasi-Asl arxiv.org [𝚌𝚜.𝙰𝙸 𝚌𝚜.𝙻𝙶] 💬Code: wcquesera/bullpen t.co

@kela9123 This should work, no? seracio/hawkeye

어제 공개됐는데 이미 떠버린 HTML 애니 깃허브 The Moss Keeper (ChetasLua) 이끼 거인이 깨어나는 손그림풍 애니 숏 HTML 파일 하나 · 빌드·의존성 없음 Fable 5.5 · base64 MP4 내장 ★129 (공개 1일) ChetasLua/moss-keeper t.co

A private search engine for visited web pages and local files, Hister indexes full contents for local querying. Replaces cloud-reliant history searches with a local engine accessible via web, terminal, or MCP. asciimoo/hister

denpa <-> Mirakurunのブリッジを作ってみました（AI slop）。チューナーのpriorityの付け方が微妙ですが、Mirakurun使っている方は簡単に試せるようになると思います multiverse2011/denpa-mirakurun-bridge

I flagged this repo at 919 stars. 2 days later it has 2,326. floorplan: Claude or Codex draws a plain-English map of your app. Parts, files, requests, even across repos. Flags keys left in code. Still climbing on ossradar.net. 🎥 Hayden Smith haydenschmitty/floorplan t.co

Recipe, FP8 and NVFP4: github.com/atakann/dgx-spark-recipes/blob/main/re… Its client writes .srt subtitles with speaker tags.

Auto Lock via NEMESIS Facebook post from Kia EV6 owners forum says the developer made an auto lock for his 22 EV6 using NEMESIS. Info can be found at s2kwinston/gen5-autolock I still prefer hardware on this one but you do you 😉

My RP2040 RTOS is now open source — next I'd like to visualize what's happening inside it A few months ago, I posted here about getting my experimental RTOS running on the Raspberry Pi Pico, first with basic kernel functions and later with six preemptive tasks. Since then, the project has developed into a new RTOS called Karqri, and I've now published the source code on GitHub: noboru-takahashi/karqri Karqri is an experimental RTOS inspired by CHARM-II, a Motorola 68000 RTOS I developed in 1986. It's a new implementation rather than a direct port of the original code. The current version runs on both RP2040 and POSIX, using a shared kernel with platform-specific task switching. On the Pico, it uses SVC/PendSV and timer interrupts for preemptive multitasking. The six-task demo has tasks A–F moving along three tracks, coordinating access to a shared critical section through event notifications. I've also added validation scenarios to test task scheduling, event handling, and context switching on the Pico. But getting the RTOS running is only part of what I want to do. My next goal is to make its internal behavior visible. For example, I'd like to show when a task is running or waiting, what event causes it to wake up, and how that leads to the next scheduling decision. I've already started experimenting with capturing execution traces from the Pico and converting them into HTML timelines. At the moment, this works for a specific validation scenario, but I'd like to make it more generally useful. I'm especially interested in how to do this on a resource-constrained microcontroller like the RP2040, without significantly changing the timing of the system being observed. I'd be interested in hearing from other Pico developers: - Have you experimented with recording or visualizing task scheduling and interrupt activity on the RP2040? - What would you find most useful to see in a visual trace of an RTOS running on a Pico? - Are there lightweight tracing techniques or tools you'd recommend for this kind of experiment? For context, here are my two earlier posts in this community: - Porting My 1986 RTOS to Raspberry Pi Pico — First Kernel Functions Running - My 1986 RTOS is now running six preemptive tasks on a Raspberry Pi Pico The source release is a milestone, but I'm hoping the visualization experiments will lead to something more interesting than just another small RTOS. I'd welcome ideas or feedback from anyone who's worked on similar problems with the Pico.

openDJ is a fast and modern open-source DJing and mixing software OpenDJ started as a Rust port of Mixxx, but it's gradually grown into its own project. Features include: - Fast GPU-rendered waveforms and 2 or 4 decks - Multiple controller support - Recording, external inputs, and broadcasting - CLAP, VST3, and AU effects and instruments - Automix with remote control from your phone - Music library management, import/export and health tools - USB Export I've started DJing with it myself, and it's been stable and fast in my use so far. Sharing here for anyone interested in DJ software, audio development, or open-source alternatives. I'd love feedback from DJs, testers, and contributors—especially people interested in helping shape and maintain the project. GitHub: sebastian-beca/opendj

I made Hypr Screen — use your Android phone as a second monitor for Omarchy (touch + keyboard, plug-and-play over USB) I wanted something like Apple's Sidecar for my Omarchy laptop, so I built Hypr Screen. Plug your Android phone in over USB and it becomes a real extra Hyprland monitor next to your laptop screen. It isn't mirroring: it has its own workspaces and Waybar, and you can drag windows onto it. Unplug it and the monitor goes away and your windows move back. What it does - Extended display at the phone's native resolution, 60 fps, hardware H.264 (VAAPI encode, MediaCodec decode). An idle desktop uses about 1 Mbit/s. - Touch: tap, drag, scroll and pinch. It shows up as a real multitouch screen mapped to the phone's monitor. - Keyboard: type with the phone keyboard, plus an extra row with Esc Tab Ctrl Alt Super and arrows. Super is sticky, so Super then 1 switches workspace. A Bluetooth keyboard paired to the phone is passed straight through. - Plug-and-play: a small user service notices the phone, opens the app and connects. No command to run. - Wi-Fi (opt-in) after one USB pairing. - Secure: TLS 1.3 with a pinned cert, the pairing key only travels over adb, and power/SysRq keys are blocked. Setup sudo pacman -S --needed wf-recorder android-tools openssl git clone kpanuragh/hypr-screen cd hypr-screen/host && ./install.sh Then install the APK from Releases on your phone (Android 11+, USB debugging on) and plug it in. It supports Hyprland 0.56's new Lua config (hyprctl eval) and falls back to the old keyword syntax. The laptop side is a single Python file using only the standard library; the APK is 76 KB. Tested on: Omarchy, Hyprland 0.56, Intel Iris Xe, OnePlus on Android 17. I haven't tried NVIDIA or other phones yet, so reports (good or bad) are very welcome. Repo: kpanuragh/hypr-screen Feedback and PRs welcome. Next on my list are an AUR package and audio.

@whoiskn0why Appreciate it. Reviews like yours are the best QA we get. Everything you flagged is fixed in public, commit by commit: wafermap/wafermap-cli Next round whenever you're ready.

こちらから日本語MODの過去verをDLできます。 github.com/Dlaqe2334/LOM-JPMOD/releases

Linux now beats macOS on Apple silicon GPU memory bandwidth. M1 Max, Omarchy: macOS: 361 GB/s Linux before: 241 GB/s Linux now: 368 GB/s The kernel never told the power controller the GPU was busy. One bit fixed it. linux-aurora#334

Pool mining takes a wallet address plus one install line: github.com/Rexemre/blockzero-docs/blob/main/how-t… Right now: 661.2 kH/s network, 91 rigs.

Preview a Django template without starting its application server A template review is easier to reproduce when the template, engine and input data are all explicit. Here is the native Django workflow being added to Arguseye, including a baseline you can compare after an edit. I’m the maker of Arguseye. This draft was prepared with AI from the project’s implementation and test records; it is not a report of production adoption. Release status: use the feat/template-previews source branch for this walkthrough. The published 0.0.15 npm and VS Code packages do not contain this work yet. 1. Use a real Python environment Your project needs its own Django installation. Arguseye uses .venv/bin/python on Linux/macOS or .venv/Scripts/python.exe on Windows when that environment exists. Another interpreter can be selected in project configuration. The template project does not need React or a package.json. The Arguseye CLI itself still requires Node.js 22+ and Chromium or Chrome. Build the development branch in a separate directory: git clone --branch feat/template-previews https://github.com/DarkWorldCoder/arguseye.git cd arguseye npm ci npm run build In the following commands, replace /path/to/arguseye and /path/to/python-app with your actual directories. No app server is started. 2. Make a small template with an include templates/card.html: <article> <h1>Hello {{ name }}</h1> {% include "items.html" %} </article> templates/items.html: <ul> {% for item in items %} <li>{{ item }}</li> {% endfor %} </ul> At the Python project root, create arguseye.templates.json: { "version": 1, "mappings": [{"pattern": "templates/**/*.html", "engine": "django"}], "roots": ["templates"], "profiles": {"example": {"name": "Ada", "items": ["Tea", "Coffee"]}} } A path mapping matters because .html can also be ordinary HTML. Template delimiters alone are not proof that Django is the correct engine. 3. Save a baseline node /path/to/arguseye/dist/cli.mjs shot templates/card.html \ --root /path/to/python-app \ --engine django --profile example \ --capture-dir /tmp/card-baseline --json --output summary The result includes accessibility text, errors, warnings, resolved inputs and native-engine metadata. The baseline directory preserves the screenshot and comparison inputs even though this command only prints a summary. Check errors and warnings before treating the result as complete. Missing context is useful evidence for the next edit. 4. Edit the partial and compare Change the list text or styling in items.html, then run: node /path/to/arguseye/dist/cli.mjs diff \ --root /path/to/python-app \ --baseline /tmp/card-baseline \ --out /tmp/card-comparison --json The comparison uses the baseline’s resolved data and viewport. It returns before/after evidence, highlighted changed pixels, accessibility changes, and new or resolved errors. Its status is unchanged, changed or incomplete. A changed screenshot still needs a review. It does not establish that the edit is correct. In VS Code The matching extension build adds Preview Component to the editor, tab and Explorer context menus. Choose the engine and a data profile, then open Props to edit JSON. Unsaved template and partial edits use the same engine as CLI and MCP verification. Template updates replace the document and reset interactive state. Where a full application test is still needed This workflow renders Django’s native templates with supplied context. It does not automatically run views, middleware, context processors or database queries. Project tags and filters need explicit setup. Rendering trusted template code is not an OS security sandbox. The native-template guide lists the installed engine fixtures, configuration and exact adapter boundaries. Reproducible examples that expose a wrong include, escaping difference or missing context are especially useful feedback.

Other behaviour changes to check after upgrading: - prod error pages only expose message/data of createError errors - webpack/rspack dev reject unknown Host headers (add yours to devServer.allowedHosts) - cache/swr/isr only cache GET/HEAD - /api%2Fadmin now matches /api/** rules Release notes

647 new stars this week. Instead of renting datacenter GPUs for 290B+ MoE models, FreeToken streams experts across consumer CPU and GPU memory locally. FlashML-org/FreeToken

Introducing Quarry: Type-Safe ClickHouse Queries for TypeScript --- title: "Introducing Quarry: Type-Safe ClickHouse Queries for TypeScript" published: true tags: typescript, clickhouse, opensource, database canonical_url: oioannou.com description: "A ClickHouse-native query builder heavily inspired by Kysely, with composable queries and inferred results on top of the official client." --- I've been building Quarry, an open-source, ClickHouse-native query builder for TypeScript. We're using it at bold.org in application services and data-processing jobs. I wanted schema-aware query composition while keeping @clickhouse/client and direct control over the SQL. The problem isn't writing SQL. It's maintaining queries whose structure varies with application inputs, sharing aggregations across call sites, and keeping manually declared result types aligned with projections. That's what I wanted Quarry to handle. Heavily inspired by Kysely Quarry is heavily inspired by Kysely, which we already use for PostgreSQL at Bold. I like its immutable builders, schema-derived types, and API that stays close to SQL. I wanted that experience for ClickHouse. I considered using a ClickHouse dialect for Kysely. The mismatch was in the query API, not connectivity: I wanted FINAL, PREWHERE, ARRAY JOIN and ClickHouse aggregates to have first-class typed support. A dialect alone doesn't add that surface to Kysely's builder. Raw SQL and extensions remain viable, but I chose a dedicated builder rather than making them the primary interface for ClickHouse-specific queries. For this project, I was happy to give up database portability and focus on ClickHouse's syntax and result semantics. ClickHouse-native composition For example, a top-pages query over a MergeTree-backed analytics table, using a schema-typed db: let query = db .selectFrom("page_views") .select("device_type", "path") .selectExpr((eb) => [ eb.fn.count().as("views"), eb.fn.quantile(0.95, "load_time_ms").as("load_time_p95"), ]) .prewhere("site_id", "=", siteId) .groupBy("device_type", "path"); if (country) { query = query.where("country", "=", country); } const pages = await query .orderBy("views", "desc") .orderBy("path", "asc") .limitBy(3, "device_type") .execute(); This is the API I was after: ClickHouse clauses and aggregates compose with application filters, and the result type follows the query. I also wanted adoption to work one query at a time. Existing SQL can stay on the official client, and .toSQL() exposes SQL and parameter bindings for inspection or integration with handwritten statements. Types at the driver boundary One detail I care about is that the inferred types match what the driver actually returns. In the example, views is a string: count() returns UInt64, serialized as a JSON string. load_time_p95 is a number. Quarry's typed execution pins the JSON serialization settings its result types depend on and rejects conflicting overrides. Schema types can distinguish read, insert and predicate values. The checks are still compile-time: a stale schema or an incorrect type annotation on a raw expression can invalidate the inferred result. Try it on one query The introspection CLI generates TypeScript definitions from existing tables, views and dictionaries for use with createClickHouseDB<DB>({ client }). It is experimental and ships separately as @oorestisime/quarry-cli. Handwritten interfaces work too; there's no schema DSL or migration system to adopt. Quarry is at 0.10.0, and minor releases may still change the API. The documentation includes a runnable example, and the playground lets you inspect generated SQL without a database. If you're composing ClickHouse queries in TypeScript, try it on one of the queries you already maintain. I'm especially interested in examples where the builder falls short or infers the wrong type. Bring one to the issue tracker. I'd rather shape the next release around real queries than a generic SQL feature checklist. --- I'm Orestis, VP of Technology at bold.org. On the side I build clssrm, simple booking software for small studios. More of my writing is on oioannou.com.

@LH @ZedLang Messing around, built a dead branch checker: flowerornament/zed-testgen

Appreciate it! If you ever want to try it on your own machine, the guide is short: github.com/Rexemre/blockzero-docs/blob/main/how-t…

GitHub Actions OIDC AWS: Secure CI/CD Without Access Keys --- title: "GitHub Actions OIDC AWS: Secure CI/CD Without Access Keys" published: true description: "Configure GitHub Actions OIDC with AWS IAM roles, temporary STS credentials, secure trust policies, and secretless CI/CD workflows." tags: devops, aws, githubactions, security canonical_url: blog.naveedkumbhar.com --- Originally published on Naveed Ahmed's Engineering Blog. Still storing AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY in GitHub Actions secrets? It works, but it also means managing long-lived credentials, rotation, and the risk of those keys being exposed. For workflows deploying to AWS, there's a better option: OpenID Connect (OIDC). GitHub Actions can use OIDC federation to request temporary AWS credentials without storing permanent AWS access keys. Here's how it works. 1. Understanding GitHub Actions OIDC The authentication flow looks like this: GitHub Actions | | Request signed OIDC JWT v GitHub OIDC Provider | | JWT v AWS STS | | Validate IAM role trust policy v Temporary AWS Credentials | v Deploy to AWS AWS uses AssumeRoleWithWebIdentity to exchange the signed token for temporary credentials after validating the issuer, audience, and allowed subject. 2. Register the GitHub OIDC Provider in AWS Configure an IAM OIDC identity provider with: Provider URL: https://token.actions.githubusercontent.com Audience: sts.amazonaws.com You can configure it in the AWS IAM console, AWS CLI, or Terraform. For production, keeping identity infrastructure in Terraform helps make the configuration reviewable. 3. Configure a Restricted IAM Trust Policy This is the most important step. A trust policy should identify the GitHub repository and deployment context that may assume the role. For example, a branch-scoped policy condition can look like: { "StringEquals": { "token.actions.githubusercontent.com:aud": "sts.amazonaws.com", "token.actions.githubusercontent.com:sub": "repo:YOUR_ORG/YOUR_REPO:ref:refs/heads/main" } } This is the condition portion of a trust policy, not the complete policy document. For repositories using GitHub's newer immutable OIDC subject format, adjust the value to match the actual token. Avoid broad wildcards that unintentionally authorize additional repositories or workflows. Also restrict the permissions attached to the role. A tightly scoped trust policy won't help much if the role has unnecessary administrator access. 4. Configure GitHub Actions The workflow needs permission to request an OIDC token. name: AWS OIDC Authentication on: workflow_dispatch: permissions: id-token: write contents: read jobs: verify-aws: runs-on: ubuntu-latest steps: - name: Configure AWS credentials uses: aws-actions/configure-aws-credentials@v4 with: role-to-assume: arn:aws:iam::123456789012:role/github-oidc-role aws-region: us-east-1 - name: Check caller identity run: aws sts get-caller-identity Replace the example AWS account ID and IAM role. For production, pin third-party and security-sensitive actions to reviewed commit SHAs. The important point: id-token: write authorizes requesting an OIDC token. It does not grant AWS permissions by itself. AWS evaluates the role trust policy before allowing role assumption. 5. Common OIDC Authentication Problems If you encounter AccessDenied or a role-assumption failure, check: - The IAM identity provider exists in the correct AWS account. - The token audience matches the trust policy. - The subject claim matches the repository and deployment context. - The job has id-token: write. - The role ARN is correct. - The workflow is running from an allowed branch or protected environment. If you use GitHub Environments, remember that the OIDC subject format differs from a branch-scoped subject. 6. Production Security Checklist For a safer setup: - Restrict IAM trust to authorized repository identities. - Use protected branches and deployment environments. - Grant only necessary AWS permissions. - Keep development and production roles separate. - Review third-party GitHub Actions. - Monitor role assumption and AWS API activity through CloudTrail. - Avoid exposing temporary credentials in workflow logs. OIDC removes the need to store permanent AWS keys for this authentication flow. It doesn't eliminate the need for secure workflow code and IAM design. --- Read the Complete Tutorial My full guide includes detailed OIDC architecture, AWS CLI and Terraform configuration, trust policy examples, GitHub Actions YAML, and troubleshooting. GitHub Actions OIDC AWS: Full Secretless CI/CD Guide --- Final Thoughts Replacing static AWS keys with temporary credentials is a useful security improvement. But the real protection comes from combining OIDC with strict IAM trust policies, least privilege, and protected deployment workflows. Have you implemented GitHub Actions OIDC for your AWS deployments? --- Written by Naveed Ahmed — DevOps & Platform Engineering Engineering Blog | Kubernetes Mastery | GitHub

@RyanAstonishing frontendx.dev linkedin.com github.com/rashidtvmr

We built EDA-Agent with deterministic AST analysis first, pushing latch detection F1 to 91.7% and testbench generation speed up by 12×.github.com/aachcoder47 ​Looking for systems engineers & chip designers to stress-test the implementation, submit PRs, or feedback.

llamAmpereのGitHubリポジトリ（独自量子化フォーマット「AmperInteger+」の実装） JakeATX/llamAmpere Hugging Faceのモデルページ（qwen3.8-27b-Swift1.5-Uncensored-ATX-AI2） huggingface.co Redditの議論スレッド（12GBカード向け2.3bpwモデルの報告） reddit.com

Huge props to @CheaperInfer for building such a bulletproof architecture that routes 375 providers into one seamless endpoint. Seriously slick workflow for dropping this straight into Cursor and Claude Code with zero friction 🚀 🔗 项目地址：cheaper-inference/OmniRoute

p-e-w/heretic のプルリクエスト #211（ARAの提案と実装の詳細はここから確認できます） heretic#211

Win11 右键折成两层，复制文件路径要先点「显示更多选项」。改注册表的方法更新后就失效。 breeze-shell 脚本重写右键菜单：常用项一层直达，可自定义项和样式，不改系统文件。 std-microblock/breeze-shell

購買オーダごとに、仕入先に請求書を送ってもらう自社の住所を選べるOCAモジュール purchase_company_invoice_address を提案していましたが、無事マージされました。Odoo 16.0向けです。 purchase-workflow#3177 複数の拠点で購買する会社では、請求書の送り先を拠点ごとに分けたいことがあります。Odooでは自社の連絡先に拠点ごとの住所を登録できますが、購買オーダには、どの住所に請求するかを仕入先に伝える項目がありません。 ・購買オーダに「請求先住所」の項目を追加します。自社（本社）か、自社の連絡先に登録した請求先住所から選べます。 ・請求先住所を登録してあれば、新しい購買オーダにはその住所が初期値として入ります。担当者が別の拠点に変えることもできます。 ・購買オーダと見積依頼書の印刷に、仕入先の住所と並べて請求先住所を表示します。本社の住所はヘッダに印字されるため、本社を選んだときは表示しません。 #Odoo #OCA #オープンソース

OpenTofu or Terraform: What to Pick for Existing Code Originally published on kuryzhev.cloud --- <p>The question of OpenTofu or Terraform tends to arrive on a quiet Tuesday. A repo with 200 resources, a remote state in S3 and a CI pipeline pinned to <code>terraform</code> works fine, until someone asks whether the next upgrade should be to the other tool. Nothing is broken, so the real question is whether switching buys anything that justifies the risk.</p> <p>The timing is worth noting. Both projects shipped new minor cycles recently: OpenTofu 1.13 (latest patch 1.13.5, cycle released 2026-09-30, <a href="github.com/opentofu/opentofu/releases">release notes</a>) and Terraform 1.17 (latest patch 1.17.1, cycle released 2026-10-21, <a href="github.com/hashicorp/terraform/releases">release notes</a>). Anyone planning a quarterly upgrade has two fresh targets. The two projects follow independent roadmaps, so check each changelog for features that exist in only one of them.</p> <p><strong>Short answer:</strong> if your code is plain AWS/GCP/Azure/Kubernetes resources and you have no contract with HCP Terraform, you can usually stay on Terraform 1.17 or move to OpenTofu 1.13 at low risk, so choose based on licensing and features. If you depend on HCP Terraform, Stacks or other HashiCorp-hosted services, stay on Terraform. If you want client-side state encryption or an open-governance licence, trial OpenTofu with the dry-run below before committing.</p> <h2>When the OpenTofu or Terraform choice actually matters</h2> <p class="devops-inline-image"></p> <p>For a small repo with a single backend, the choice is mostly cosmetic. It starts to matter in four situations:</p> <ul> <li><strong>Licensing review.</strong> Terraform releases after 1.5.x use the Business Source License; OpenTofu is MPL-2.0 under the Linux Foundation. Legal teams sometimes care, particularly if you ship tooling to customers. Read the current licence text yourself rather than relying on a blog summary.</li> <li><strong>State sensitivity.</strong> State holds secrets in plain text unless the backend encrypts it. OpenTofu has built-in state and plan encryption. Terraform relies on backend encryption and on its ephemeral and write-only mechanisms to keep values out of state. Check the Terraform docs for what your version supports.</li> <li><strong>Platform coupling.</strong> If your org runs workspaces, policies and run tasks in HCP Terraform or Terraform Enterprise, the tool and the platform are one decision.</li> <li><strong>Feature divergence.</strong> Since the 2023 fork the two projects have added different features and, in some cases, different syntax for similar ideas. Config that uses a tool-specific feature will not run on the other.</li> </ul> <p>Neither tool has a blanket advantage. Compare the changelogs for your specific version jump, not for the headline releases.</p> <h2>Option A: OpenTofu 1.13</h2> <p><strong>Pros</strong></p> <ul> <li>Open governance and an MPL-2.0 licence, which simplifies procurement and redistribution questions.</li> <li>Native state and plan encryption with pluggable key providers (including AWS KMS), configured in the <code>terraform</code> block. This matters when state lands in shared buckets.</li> <li>Features that landed after the fork, such as <code>for_each</code> on providers and the <code>-exclude</code> flag, are documented on <a href="opentofu.org">opentofu.org</a>. Confirm what is in 1.13 against its changelog.</li> <li>Same HCL, same provider protocol, same workflow. The binary is <code>tofu</code> and the commands match, so the CLI is familiar.</li> </ul> <p><strong>Cons</strong></p> <ul> <li>Migration becomes effectively one-way once you encrypt state or adopt OpenTofu-only syntax. Terraform cannot read encrypted state, so going back means decrypting with OpenTofu or reverting the config first.</li> <li>Provider and module sourcing goes through the OpenTofu registry. Your <code>.terraform.lock.hcl</code> entries will change, and any tooling hard-coded to <code>registry.terraform.io</code> needs a check.</li> <li>Third-party integrations (scanners, IDE plugins, CI templates) vary in how well they support <code>tofu</code>. Test yours rather than assuming.</li> <li>Commercial support comes from vendors rather than the original authors, which may or may not matter to your org.</li> </ul> <h2>Option B: Terraform 1.17</h2> <p><strong>Pros</strong></p> <ul> <li>Zero migration. Your pipeline, lock files, runbooks and team habits stay as they are, and upgrades inside the 1.x line follow the documented <a href="developer.hashicorp.com">upgrade guides</a>.</li> <li>First-party integration with HCP Terraform and Terraform Enterprise, including features that exist only there (Stacks, hosted policy and drift tooling). HashiCorp is now part of IBM, so vendor support contracts are a single conversation for many enterprises.</li> <li>Most vendor docs and provider examples still assume <code>terraform</code>, so troubleshooting is easier to search.</li> </ul> <p><strong>Cons</strong></p> <ul> <li>The BSL licence restricts offering a competing product. Most internal use is fine, but verify the terms against your situation, especially if you resell infrastructure automation.</li> <li>No built-in client-side state encryption. You depend on backend-side encryption (for example S3 with KMS) and on keeping secrets out of state in the first place.</li> <li>Roadmap and licence decisions sit with one vendor. That is a trade-off, not a defect, but it is a dependency you should name.</li> </ul> <h2>Decision matrix</h2> <table> <thead><tr><th>Situation</th><th>Lean toward</th><th>Why</th></tr></thead> <tbody> <tr><td>HCP Terraform / Enterprise in daily use</td><td>Terraform 1.17</td><td>Platform features are tied to the vendor CLI</td></tr> <tr><td>Self-managed CI with S3/GCS backend</td><td>Either</td><td>Low switching cost; decide on licence and features</td></tr> <tr><td>Need encrypted state independent of the backend</td><td>OpenTofu 1.13</td><td>Built-in encryption block</td></tr> <tr><td>Legal requires an OSI-approved licence</td><td>OpenTofu 1.13</td><td>MPL-2.0</td></tr> <tr><td>Heavy use of vendor-supported Terraform tooling</td><td>Terraform 1.17</td><td>Fewer integration surprises</td></tr> <tr><td>Config written for a much older Terraform (1.5.x or earlier)</td><td>Upgrade first, decide later</td><td>Big version jumps are the risk, not the tool</td></tr> <tr><td>Small team, no pain today</td><td>Stay put</td><td>Switching has a cost and no immediate payoff</td></tr> </tbody> </table> <p><strong>Watch out:</strong> do not combine a tool switch with a major provider upgrade in one change. When a plan shows unexpected diffs, you want exactly one variable to blame.</p> <h2>Evidence-based recommendation</h2> <p>The evidence for an urgent move in either direction is thin. Both tools plan and apply the same core HCL against the same providers. The differences that matter are licence, state handling, and platform lock-in, and you can evaluate those without touching production.</p> <p>So the practical approach is a read-only trial. The following runs OpenTofu against a copy of your current setup. It takes a state backup first, then produces a plan and never applies. Run it from a branch.</p> <pre><code class="language-bash"># 1. Back up current state with the tool you use today terraform state pull &gt; ../backup-$(date +%F).tfstate 2. Check versions; OpenTofu evaluates required_version against its own version number, so review any terraform { required_version } constraint terraform version tofu version 3. Re-init with OpenTofu (rewrites .terraform.lock.hcl; review the diff) rm -rf .terraform tofu init tofu providers lock -platform=linux_amd64 -platform=darwin_arm64 4. Read-only comparison: -lock=false avoids blocking teammates; never apply here tofu plan -lock=false -detailed-exitcode echo "exit code: $?" </code></pre> <p>To verify the result, check the exit code. <code>0</code> means no changes, which is what you want from an unchanged codebase. <code>2</code> means a diff, so read it before you do anything else. <code>1</code> is an error, typically a provider source or backend setting. If the plan is clean, run the same steps in CI on a non-production workspace.</p> <p><strong>Watch out:</strong> run <code>tofu apply</code> only on a workspace you can afford to roll back. A newer tool can write state that the older one refuses to read, and the backup from step 1 is your way out.</p> <p>If the trial is clean and you want OpenTofu's encryption, add it deliberately as a separate change. Existing state is unencrypted, so the first configuration needs an unencrypted fallback to read it. This example uses AWS KMS; the key alias is a placeholder for your own.</p> <pre><code class="language-hcl"># encryption.tf (OpenTofu only; Terraform will reject this block) terraform { encryption { key_provider "aws_kms" "main" { kms_key_id = "alias/tofu-state" # your KMS key alias region = "eu-west-1" key_spec = "AES_256" } method "aes_gcm" "default" { keys = key_provider.aws_kms.main } # Temporary: lets OpenTofu read the existing unencrypted state method "unencrypted" "migrate" {} state { method = method.aes_gcm.default fallback { method = method.unencrypted.migrate } } } } </code></pre> <p>After the next <code>tofu apply</code> writes encrypted state, remove the <code>unencrypted</code> method and the <code>fallback</code> block, and add <code>enforced = true</code> inside <code>state</code> so OpenTofu refuses to write unencrypted state. Verify by reading the raw object from the backend rather than through <code>tofu</code>, which decrypts transparently, for example <code>aws s3 cp s3://&lt;your-state-bucket&gt;/&lt;your-state-key&gt; - | head -c 200</code>. Encrypted state is a JSON envelope with encryption metadata instead of readable resource attributes. Details, plan encryption and rollback options are in the <a href="opentofu.org">OpenTofu documentation</a>, so follow those rather than improvising.</p> <p>The recommendation, with conditions:</p> <ul> <li><strong>Stay on Terraform 1.17</strong> if you use HCP Terraform or Enterprise, or if nothing in the matrix hurts today.</li> <li><strong>Move to OpenTofu 1.13</strong> if licence terms or state encryption are real requirements, and the dry-run above shows a clean plan.</li> <li><strong>Do neither yet</strong> if you are several minor versions behind. Upgrade within your current tool first, then compare.</li> </ul> <p>For related infrastructure patterns, browse more guides on <a href="kuryzhev.cloud">kuryzhev.cloud</a>. Whichever way you go, pin the binary version in CI so the choice stays a decision and never becomes drift.</p> <h2>Related</h2> <ul> <li><a href="kuryzhev.cloud">Terraform Vault Secrets: Keep Them Out of State and Git</a></li> <li><a href="kuryzhev.cloud">Terraform Modules for AWS VPC, IAM, and S3: Structure That Scales</a></li> <li><a href="kuryzhev.cloud">Why an LLM reviewer misses risky Terraform plan changes</a></li> </ul>

@nikolay_dp Could you take a look at this pr. Cant use any codex in monocode anymore :( monocode#1297

List of research on Large Language Models for software vulnerability detection huhusmang/Awesome-LLMs-for-Vulnerability-Detection #infosec #llm t.co

From my 1986 RTOS to Karqri: What should I visualize next? Over the past several months, I've posted here a few times about revisiting CHARM-II, an RTOS I developed for the Motorola 68000 back in 1986. What started as an attempt to restore and understand my old source code gradually turned into a new development project. After reconstructing parts of the original system on POSIX, getting preemptive multitasking working on the Raspberry Pi Pico, and revisiting some of my old scheduling decisions, I decided to build a new RTOS rather than continue trying to reproduce the original one. I've named it Karqri, and I've now published the source code on GitHub: noboru-takahashi/karqri Karqri currently runs on POSIX and RP2040, with a shared kernel and a six-task demo running in both environments. It's still experimental, but I've implemented and tested the basic RTOS mechanisms. However, building the RTOS itself isn't the only goal of this project. What I'd like to explore next is how to visualize what's happening inside an RTOS, including not just task states and scheduling decisions, but also the timing and causal relationships between events. For example, imagine a task waiting for an event. Another task sends a notification, the waiting task becomes runnable, and the scheduler eventually selects it to run. I'd like to represent that sequence as a connected series of events, rather than just a collection of log messages. I've already started experimenting with capturing execution traces from the Pico and generating HTML timelines. At the moment, this is limited to a specific validation scenario, but I'd like to develop it into something more general. I'm curious what other OS developers think about this direction. - If you were visualizing the internal behavior of an RTOS, what information would you find most useful? - How would you capture causal relationships between events without significantly disturbing the timing of the system being observed? - Beyond debugging and education, can you think of other useful applications for this kind of visualization? For context, here are a few of my earlier posts: - Visualizing a 1986 RTOS in a Modern Browser - My 1986 RTOS is now preemptively multitasking on a Raspberry Pi Pico - and it made me question whether I need an RTOS - Follow-up: What I learned about VRTX's equal-priority scheduling in the 1980s This project began with rediscovering an RTOS I wrote 40 years ago, but it has gradually become something quite different. Publishing Karqri is the first milestone in that new direction, not the end of the project.

I made a tiny open-source replacement for the LOVINGCOOL / Thermalright LCD apps (20 MB RAM vs 530 MB) Got tired of the vendor apps running 8 background processes just to show a picture, so I wrote LcdWall: one tray app that drives both LOVINGCOOL and Thermalright Trofeo Vision screens. ~20 MB RAM, ~0.1% CPU Images, GIFs, videos, .zt themes One-click import from the vendor apps No installer, no drivers, free and open source (GPL-3.0) Windows 10/11. Tested on the LOVINGCOOL 6.67" and Trofeo Vision 9.16", so tell me if it works on other models. Download + source: RvaByte/LcdWall

Agents Edit Faster Than Git's Clock Ticks: The 'Racy Git' Problem, Explained - Book: System Design Pocket Guide: Interviews - Also by me: Thinking in Go (2-book series) — Complete Guide to Go Programming + Hexagonal Architecture in Go - My project: Hermes IDE | GitHub — an IDE for developers who ship with Claude Code and other AI coding tools - Me: xgabriel.com | GitHub --- When you run git status, Git mostly doesn't read your files. It reads a cache of their metadata, stored in the index, and if that metadata hasn't moved, it trusts that the file hasn't either. That shortcut has a hole, and Git's own technical documentation names it: racy git. Change a file, stage it, then change it again in place, without changing its size, inside the same timestamp tick. The cached metadata still matches. A naive check would call the file clean while its contents are different. For years this was an edge case for fast typists and scripts. A coding agent changes the odds. It can make several edits to one file back to back with no human pause in between, and a tool can ask Git "what changed this turn?" the instant the agent stops. Same second, same size, one flipped digit: that is the shape of the race, whenever the agent's edit tool writes the file in place rather than through a rename. Git has a defense for it, and you can watch the defense work with a short shell script. How Git decides a file is unchanged The index records every tracked path with the object name of its contents. To avoid hashing every file on every command, each entry also caches the lstat(2) data from the moment it was last updated. According to the racy-git document, Git compares the file type, the executable bit, st_mtime, st_ctime, st_uid, st_gid, st_ino and st_size. If they all match, Git treats the file as unchanged and never opens it. A different size or file type is enough to call it modified. If only a timestamp or the inode moved, Git reads the contents to be sure. The timestamps are the weak spot. The same document says that comparing the nanosecond part of the timestamps is optional, and that on Linux it is off by default, because in-memory timestamps can be finer than what the disk keeps. In that default, the tick is one second. Two writes in the same second carry the same st_mtime. So the race needs all of these at once: - The file is rewritten in place, so the inode stays the same. A tool that writes a temp file and renames it gets a new inode, which sends Git to the contents. - The new contents are the same length, like retries = 3 becoming retries = 5. - The rewrite lands in the same tick as the index write that recorded the old version. !A pocket watch whose second hand is frozen on one tick while two nearly identical document pages sit stacked on its face Two versions of a file, one tick on the clock: the stat cache can't tell them apart. Git's two defenses The racy-git document describes two mechanisms, and Git's read-cache.c implements both. The first is a suspicion rule. The index file is written after Git collects the stat data of the paths it records, so its own st_mtime is usually the same as or newer than any file it lists. An entry whose st_mtime is the same as or newer than the index file's timestamp is "racily clean": it looks clean but might not be. For those entries, Git doesn't trust the stat match. It compares the file's contents with the object recorded in the index. In the source, is_racy_stat makes that call, and ie_match_stat falls back to ce_modified_check_fs to check the contents. The second covers a later problem. Suppose the index is rewritten a few seconds later, for some unrelated reason. Its timestamp moves forward, the old entry no longer looks racy, and the stat data would match again. To close that gap, when Git writes an index that contains a racily clean entry, it truncates that entry's cached st_size to zero. In ce_smudge_racily_clean_entry, Git checks the contents first and only zeroes the size when they really differ. A cached size of 0 never matches a non-empty file, so every later comparison falls through to a content check. The defense costs time. The document's "Runtime penalty" section makes every entry in a Linux kernel checkout (over 20,000 files at the time) racily clean on purpose. git diff-files then took 2.22 seconds. After git update-index MAINTAINERS wrote a fresh index, the same command took 0.14 seconds. Those timings come from an Athlon 64 X2 3800+, a mid-2000s desktop CPU, so the ratio is what carries over. That is one reason the first git status after a burst of edits can be slower than the next one. Per the git status manual, status refreshes the index by default, "updating the cached stat information from the working tree and writing out the result". Once a fresh index is on disk with a newer timestamp, the entries that really are clean stop being suspicious, and the hashing stops. Watch it happen: a one-second script This script waits for the start of a fresh second, then stages a file, rewrites it in place with the same length, and writes the index again, all inside that second. Then it waits, writes the index a third time, and asks Git for status. It runs in a throwaway directory from mktemp -d and touches nothing else. #!/usr/bin/env bash # racy.sh: rewrite a tracked file in the same second # as an index write, then watch Git catch it. set -eu cd "$(mktemp -d)" git init -q # start at the top of a fresh second s=$(date +%s) while [ "$(date +%s)" = "$s" ]; do :; done a=$(date +%s) printf 'retries = 3\n' > conf.txt printf 'notes\n' > notes.txt git add conf.txt # index write 1 printf 'retries = 5\n' > conf.txt # same size, same inode git add notes.txt # index write 2 b=$(date +%s) if [ "$a" != "$b" ]; then echo "crossed a second boundary, run it again" exit 1 fi echo "cached entry for conf.txt after write 2:" git ls-files --debug conf.txt | grep 'size:' sleep 2 printf 'later\n' > later.txt git add later.txt # index write 3 git status --short I haven't run this script myself, so here is what the source says should happen, step by step, and what to look for. During git add notes.txt, Git writes a new index. The conf.txt entry has the same st_mtime second as the previous index file, so it is racily clean. Git reads its contents, sees retries = 5 where the index recorded retries = 3, and zeroes the cached size. git ls-files --debug prints the cached stat data per entry, and its source prints the cached size on a line that starts with size:. If the race happened, you should see size: 0 there, even though the file on disk is 12 bytes. Two seconds later, git add later.txt writes the index again with a newer timestamp. Now conf.txt no longer looks racy by time. Its mtime and inode would still match, and if the size were still 12, a stat-only check would call it clean. Because the size is 0, it can't match, and git status --short should list conf.txt as AM: added to the index, then modified in the working tree. One caveat. If your Git build compares nanosecond timestamps, the second write already has a different st_mtime, so Git compares contents, finds the change, and you'll see the real size instead of 0. The status line comes out the same. That's the correct answer by a different route. What this means for tools that watch agents Everything that reports what an agent did goes through some version of this question: did this file change since I last looked? Your prompt's dirty marker, a pre-commit hook and a per-turn snapshot tool all ask it, sometimes right after the agent's last write. If you write your own mtime-and-size check instead of asking Git, you inherit the race without the defense Git already ships. If a tool runs git status in the background while the agent works, the same manual warns that the index write takes a lock that can make other Git processes fail, and points scripts at git --no-optional-locks status. A watcher shouldn't make the agent's own git commit fail. This is where I declare an interest: I build Hermes IDE, so weigh this section with that in mind. Hermes saves every agent turn, so you can diff or restore a single turn, with undo, and the Review Desk (⌘G) shows changes by turn or by file (README). Any per-turn snapshot is taken when a turn ends, which is when a same-second, same-size edit is most likely. That's why the logic in this post matters to me: a turn that looks empty when it changed 3 to 5 would be a nasty bug in a review tool. !The Hermes IDE Review Desk in By turn view, listing two turns of a Claude Code task with turn 1's diff of src/db.ts and a drafted commit message The Review Desk (⌘G) in By turn view: two turns of a Claude Code task in orders-api, turn 1's diff of src/db.ts adding a refunded status, and a commit message drafted from the turns. Hermes is free, source-available under BSL 1.1, and runs on macOS, Windows and Linux. You can download it or read the code on GitHub. It runs agents such as Claude Code in their own terminals and isn't affiliated with any agent vendor. If you build a watcher The stat cache bets that metadata moves when contents do; racy git is where it doesn't. If you build anything that watches an agent's working tree, the cheapest correct move is to ask Git and let it pay for the hashing. If you must roll your own change detection, copy both rules from the document: treat anything as new as your last snapshot as suspect, and record that suspicion so it survives the next write. And run the script above on your own machine before you trust either. --- If this was useful Racy git is a cache-invalidation trade-off in miniature: a fast check, a known blind spot, and a fallback that costs time only where the blind spot is. That is the kind of reasoning a system design interview asks you to say out loud, and my System Design Pocket Guide: Interviews walks through 15 real designs step by step with the trade-offs named. 

Stop copying chunks of an agent's answer just to explain what needs changing. Open-source Plannotator opens the last reply for annotations and sends your feedback back: /plannotator-last, or $plannotator-last in Codex. backnotprop/plannotator

Switch 玩家注意：你的 Joy-Con 放着不用，也可能一直在偷偷耗电 JoyOff 可以将原装 Joy-Con 切换至运输低功耗模式并断开连接，适合长期收纳，不需要电脑即可操作 有需要的朋友赶紧试试，享受吧 sthetix/JoyOff

Pre-Game Thread | COL @ CBJ | 2026-11-03 5:00 PM MST GameCenter: Colorado Avalanche @ Columbus Blue Jackets Start Time: 5:00 PM MST | Venue: Nationwide Arena | Networks: CBJNHL, CBJHN, ALT Referees: TBD | Linesmen: TBD Last Update: 11/3/2026, 3:54:16 PM --- Standings | Team | Rank | GP | W | L | OT | PTS | PTS% | L10 | STRK | |---|---|---|---|---|---|---|---|---|---| | COL | 7 | 15 | 9 | 5 | 1 | 19 | .633 | 6-3-1 | W3 | | CBJ | 29 | 12 | 5 | 7 | 0 | 10 | .417 | 4-6-0 | L2 | --- Team Stats | Team | GF/GP | GA/GP | DIFF | |---|---|---|---| | COL | 4.27 | 3.07 | +18 | | CBJ | 2.42 | 3.25 | -10 | --- Goalies | Team | Goalie | Record | GAA | SV% | SO | |---|---|---|---|---|---| | COL | M. Blackwood | 8-3-0 | 2.66 | .899 | 0 | | COL | S. Wedgewood | 1-2-1 | 3.48 | .889 | 0 | | CBJ | J. Greaves | 2-5-0 | 3.11 | .883 | 1 | | CBJ | C. Talbot | 3-2-0 | 2.83 | .894 | 0 | --- Top Skaters | Team | Player | G | A | PTS | +/- | ATOI | |---|---|---|---|---|---|---| | COL | N. MacKinnon | 9 | 16 | 25 | +8 | 20:33 | | COL | M. Necas | 7 | 11 | 18 | +12 | 19:43 | | COL | A. Lehkonen | 12 | 5 | 17 | +15 | 18:46 | | CBJ | K. Johnson | 7 | 5 | 12 | +1 | 17:40 | | CBJ | Z. Werenski | 0 | 10 | 10 | +4 | 28:50 | | CBJ | C. Coyle | 1 | 8 | 9 | -1 | 19:41 | --- Scratches No scratches reported. --- Season Series (First meeting) | Date | Away | Home | Score | |---|---|---|---| | Nov 3 | COL | CBJ | TBD | | Feb 15 | CBJ | COL | TBD | --- GameDayLive is an [open source project](<Arctyc/GameDayLive>) that is not affiliated with any organization.

SpikeStrip: Reversible HTML and JavaScript prompt decoys with opaque per-insertion keys.

Ory Kratos API Exposure and the Small-Sample Problem Ory Kratos API Exposure and the Small-Sample Problem Ory Kratos is an API-first identity system, so its public surface may not look like a conventional login portal. A small external count can still be useful, provided the analyst does not use it to estimate adoption or risk. Sparse observations require more caution, not less. The selected count-only query for title="Ory Kratos" used scope all, page 1, and one result on 2026-11-03. It returned two matches. The application fingerprint query returned zero in the same run. That combination is a weak external signal. It tells us that a title keyword produced a very small candidate set, not that only two Kratos deployments exist. Why the sample stays small Kratos can be deployed headless, behind a custom frontend, or under a product or tenant name that does not include "Ory Kratos" in the page title. A title search therefore misses most deployments by design. Some APIs return JSON or minimal responses rather than pages with titles. A small count is evidence about the query, not a statement about the product's global footprint. Use the two candidates only as leads. Confirm ownership and product identity through an authorized endpoint or inventory. Do not scan for API paths or test authentication behavior without permission. The fact that an identity service has a public API does not make it safe to probe arbitrary tenants. Review identity configuration If the service is owned, review tenant isolation, public API routes, CORS settings, session and cookie configuration, and the exposure of administrative functions. Confirm the identity schema and recovery flows match the business policy. Check logs for unexpected account creation, recovery attempts, and session anomalies. Identity systems also need version and migration discipline. A small sample can hide that a deployment is behind on security updates or uses a custom frontend with a different control surface. Keep version evidence and configuration ownership separate from an external title count. Report the evidence plainly Write the query, scope, page, timestamp, and count. Say "two title matches were observed" rather than "two Kratos services were found." Record the zero-result application query as part of the method. That context prevents a reader from treating a sparse dataset as a complete census. ZoomEye is useful here as a reminder to check an identity system's external population and to compare it with internal inventory, even when the public count is small. The next step is an owner-led configuration review. For a service that handles authentication, a small number of unknown hosts can still deserve prompt attention. References - Ory, Ory Kratos documentation - Ory, Ory Kratos project - ZoomEye, ZoomEye

Large-scale LLM inference can be extremely expensive. What strategies would you use to optimize cost while maintaining… Asked in an LLM inference systems engineer interview. What they are really testing: Whether you think about inference as a system with measurable levers (throughput, latency, quality, GPU utilisation) rather than a list of tricks, and whether you can tie each optimisation to the SLO it protects. A strong answer: - Start by fixing the targets: TTFT and inter-token latency SLOs per tier, quality bar, and cost per million tokens. Without these, every optimisation is a guess. - Serving efficiency first: continuous batching, paged KV cache (vLLM-style) to cut memory fragmentation, and prefix caching for shared system prompts. These raise tokens per GPU-second without touching model quality. - Model-level levers: quantisation (FP8 or INT8 weights, INT4 where quality holds), speculative decoding for latency-bound decode, and distillation or smaller models for easy traffic. - Routing: a classifier or cascade that sends simple requests to a small model and escalates on low confidence. Measure the escalation rate and the quality delta on an eval set, not just average cost. - Capacity and scheduling: right-size tensor parallelism to the model and hardware, separate prefill and decode pools when prompts are long, use spot or preemptible capacity for batch and async workloads, and autoscale on queue depth rather than CPU. - Controls: cap max output tokens, enforce prompt length budgets, cache deterministic responses where semantically safe, and track cost per request by feature so regressions show up in dashboards. Common mistakes: - Quoting a percentage saving for quantisation or caching without checking it against your own eval suite and latency targets. - Optimising GPU utilisation alone, which can raise p99 latency and break user-facing SLOs. How would you order these levers for a team that is already in production with a fixed latency budget? Share your approach in the comments. --- Originally shared on LinkedIn. An AI interview question every day, leadership for tech people and hands-on AI learning: - Follow me on LinkedIn for daily AI updates - Follow me on GitHub for the AI projects I build - Follow me on Bluesky for AI in short - Follow me on X for quick AI takes - Follow me on Dev.to for full AI articles - Follow me on Facebook for every post, every day - Visit my AI R&D lab website

Pre-Game Thread | UTA @ TOR | 2026-11-03 5:00 PM MST GameCenter: Utah Mammoth @ Toronto Maple Leafs Start Time: 5:00 PM MST | Venue: Scotiabank Arena | Networks: Mammoth+, TSN4, Utah16 Referees: TBD | Linesmen: TBD Last Update: 11/3/2026, 3:53:14 PM --- Standings | Team | Rank | GP | W | L | OT | PTS | PTS% | L10 | STRK | |---|---|---|---|---|---|---|---|---|---| | UTA | 11 | 15 | 9 | 6 | 0 | 18 | .600 | 6-4-0 | L1 | | TOR | 13 | 16 | 8 | 6 | 2 | 18 | .563 | 5-4-1 | W1 | --- Team Stats | Team | GF/GP | GA/GP | DIFF | |---|---|---|---| | UTA | 3.60 | 3.47 | +2 | | TOR | 3.75 | 3.31 | +7 | --- Goalies | Team | Goalie | Record | GAA | SV% | SO | |---|---|---|---|---|---| | UTA | K. Vejmelka | 6-5-0 | 3.31 | .872 | 1 | | UTA | S. Cossa | 3-1-0 | 3.20 | .855 | 0 | | TOR | S. Bobrovsky | 3-5-2 | 3.29 | .885 | 0 | | TOR | A. Stolarz | 5-1-0 | 2.66 | .910 | 0 | --- Top Skaters | Team | Player | G | A | PTS | +/- | ATOI | |---|---|---|---|---|---|---| | UTA | C. Keller | 4 | 14 | 18 | -9 | 18:09 | | UTA | L. Cooley | 8 | 9 | 17 | -3 | 18:17 | | UTA | M. Sergachev | 5 | 12 | 17 | +1 | 23:39 | | TOR | A. Matthews | 11 | 13 | 24 | +7 | 20:36 | | TOR | W. Nylander | 10 | 11 | 21 | +0 | 20:07 | | TOR | J. Roslovic | 6 | 10 | 16 | +1 | 16:43 | --- Scratches No scratches reported. --- Season Series (UTA leads 1-0) | Date | Away | Home | Score | |---|---|---|---| | Oct 13 | TOR | UTA | 4-5 UTA | | Nov 3 | UTA | TOR | TBD | --- GameDayLive is an [open source project](<Arctyc/GameDayLive>) that is not affiliated with any organization.

joplin ⭐ 57k Joplin is an open-source note-taking and to-do application for developers and users who want a self-hosted, syncable notes tool. 🔗 laurent22/joplin #opensource t.co

⚡ [Top 5 AI Repos This Week] jev-ultrafast: The Free Tool Taking Over GitHub! #shorts Discover browser-use/jev-ultrafast: Fastest and cheapest web agent 💬 Comment "JEVULTRAFAST" below for the direct link, or grab it from the links below: 👉 Interactive Star History & Live Analysis: githubrepo.cloud ⭐ Embed Live Verified Badges in your README: githubrepo.cloud 🔗 Direct GitHub Repository: browser-use/jev-ultrafast 📊 Repository Specs: ⭐ Stars: 23,497 🍴 Forks: 1,769 💻 Language: Python 📜 License: MIT #shorts #jevultrafast #ai #artificialintelligence #machinelearning #deeplearning #python #datascience #llm

Filee: convert 263 file formats offline, free alternative to online converters Filee: convert 263 file formats offline, free alternative to online converters The repo: KnifeLemon/Filee Star it. Follow for tomorrow's repo. Repo Radar: one trending GitHub repo, most days. #github #opensource #coding #Shorts

By default in ASDD, AI agents review code and a person approves and merges it. Auto-merge stays off until a project has a track record, then covers only a declared class of small changes. Protected paths always need a person. OneHillAI/ASDD

Nvidia – open-source auto-ontology | Discussion