Mentions

ぬお、Mozkeyアプデきてんの？明日やる、あー、今入れたい github.com/koyasi777/mozkey/releases/tag/v1.0.0

RX580 now getting usable performance for llm inference on Hackintosh! 2 years ago this wasn't even worth the hours of experiments to try running anything on the rx580, it was slow, models were a toy and any quantization of kv cache would give you garbage results. Now TOSHllm has brought modern AMD Metal support to llama.cpp , which had always focused on Apple silicon previously. And I extended his work to improve the kernels on these old Polaris RX580's that are a great card on Hackintosh. graydini/toshllm , I've reached with in spitting distance of modern linux Vulkan , and I think I tie with ROCm but the ancient machine I'm on now (a xeon westemere) has a hardware conflict with ROCm so I can't try it and I'm not going to put it back in my old newer rig to test that. Up to 29Toks decode for Ornith 1.5 9b which is the best model I found so far to fit on 8gb with good enough context to run Hermes if I want. I was getting about 17 toks on his base line when I started this.

YO! Have a RTX 20, 30, 40 series? Do you work in fp16 or fp32? Check this out: Zagitta/gpu-unlock It gave me a gigantic speed boost on juggernaut (fp32) renders. Isnt that nice? Check out 8second Drake Toast for example: t.co

github.com/hra1129/Y8960_Cartridge/releases/tag/v… MSX-AUDIO の ADPCM の R#7 の MSB の機能を実装。 CPUから直接ADPCMを鳴らす機能。 そのテストプログラムも追加。

Two databases, one question: how I built Eligible A government benefits finder that answers one sentence, and shows its work. --- Type this: > I am a 34 year old tailor in Hyderabad, I make about 2.4 lakh a year, two kids in school You get back 488 Indian government schemes you actually qualify for. Each card names the rule that let it through. Underneath, 72 schemes that came close, each one naming the exact number that stopped it: "Your ₹2.4 lakh is ₹10,000 over the ₹2.4 lakh ceiling." That is Eligible. It reads 2,066 real schemes from the MyScheme corpus: 527 central, 1,539 state, 80 issuing ministries and departments, 13.4 million characters of eligibility prose written by clerks, not copywriters. This post is about the design decision that made it work, the four bugs that nearly broke it, and the interface rebuild that came after the first version looked too much like every other tool I have shipped. --- The wrong first design The obvious build is one table, one search, one list. schemes: name, summary, state, income_ceiling, min_age, max_age Ask for everything, filter by income and age, done in an afternoon. It fails immediately, and the failure is interesting. A tailor in Hyderabad is not searching for the word "tailor". He needs the scheme written for "artisans and weavers engaged in the handloom sector". There is no keyword overlap at all. Full text search returns nothing, and the person who most needed the scheme goes away thinking it does not exist. So the first half of the problem is meaning, and meaning wants embeddings. But the second half is arithmetic, and embeddings are terrible at arithmetic. A cosine similarity score of 0.83 says nothing about whether ₹2,40,000 sits under a ₹2,50,000 ceiling. Filtering 80 float scores in application memory means the database did nothing and the process did everything, which is exactly what the "how deliberately did you use the database" question is asking about. Eligibility is two questions. So it gets two databases. flowchart TD B["Browser<br/>React 18 + Vite, one screen"] -->|"POST /api/search"| A["Express API<br/>64 kB body cap"] A --> P["parseProfile()<br/>optional LLM, output validated"] P --> V["VectorsDB<br/>slug + embedText<br/>cosine similarity, top 80"] P --> T["TablesDB<br/>23 typed columns, 5 indexes<br/>range scans on age + income"] V -->|"slug"| U{{"union, deduped by slug"}} T -->|"slug"| U U --> R["rules.ts<br/>pure, no I/O<br/>reject only on a stated field"] R --> M["matched 488"] R --> N["near misses 72<br/>each carrying the number that killed it"] R --> L["long tail 464"] R --> C["receipt: candidates, kills, ms, which layer ran"] VectorsDB holds one document per scheme: the slug and the embedded eligibility paragraph. Nothing else. TablesDB holds the arithmetic: jurisdiction, level, minimum and maximum age, income ceiling, benefit amount, document count, women-only and disability-only flags. A slug joins them. The rule I keep coming back to: if both databases stored the income ceiling, there would be two sources of truth for the same fact, and the day they disagreed the app would start lying. The vector store knows meaning. The table knows facts. --- Reading 2,066 schemes without inventing thresholds server/extract.ts turns prose into typed facts. The hard part is not parsing. It is deciding what to do when the document says nothing. A wrong threshold is worse than a missing one. If a scheme states no income ceiling and the parser writes 0, that scheme silently excludes every human on earth. If it writes Infinity, nobody notices a broken parse until a ministry changes the rules. So the parser returns whether a rule was stated, alongside the value: export function parseIncomeCeiling(text: string): { ceiling: number; stated: boolean; clause: string } { const parts = sentences(text); let best: { ceiling: number; clause: string } | null = null; for (const sentence of parts) { const low = sentence.toLowerCase(); if (!low.includes('income')) continue; const re = /(?:₹|rs\.?|inr)?\s*(\d[\d,]*(?:\.\d+)?)\s*(crore|cr\b|lakh|lac|lacs|lakhs|thousand|k\b)?/gi; let m: RegExpExecArray | null; while ((m = re.exec(sentence))) { const value = parseRupees(m[0]); if (!value) continue; if (value < 5000) continue; if (value > 50_000_000) continue; if (!best || value > best.ceiling) best = { ceiling: value, clause: sentence.trim() }; } } if (!best) return { ceiling: NO_INCOME_CEILING, stated: false, clause: '' }; return { ceiling: best.ceiling, stated: true, clause: best.clause.slice(0, 260) }; } Three details matter more than they look: - The sentence filter. Only lines containing "income" are considered. Spend ceilings, project costs and loan amounts all say "lakh" and are not income limits. - The best rule. When a paragraph states several amounts, the parser takes the highest under "income". A scheme that says "up to ₹2 lakh, ₹2.5 lakh for SC/ST" admits everyone at 2.4 lakh if you take the wrong one. Taking the maximum is the choice that broadens access, which is the safer error for a benefits tool. - The clause. Every ceiling keeps the sentence it came from, so the UI can show the government's own words instead of a number with no provenance. The same shape applies to age bands and to the two flags that cannot be guessed: womenOnly and disabilityOnly. Those are computed with left anchored regexes, because the first version matched male inside female and turned a women's scheme into a men's scheme. --- The engine, and the comment that is a bug report server/rules.ts is a pure function. No database, no network, no model. That is deliberate: the decision is the part that has to be auditable, so it is the part with no dependencies. // Central schemes apply everywhere, however the row spells it: a table that // stores `level = central` must not be judged by the string in jurisdiction. const everywhere = scheme.level === 'central' || scheme.jurisdiction === 'All India' || scheme.jurisdiction === 'Central' || !scheme.jurisdiction; if (!everywhere && profile.state) { if (scheme.jurisdiction === profile.state) { reasons.push(`${scheme.jurisdiction} scheme`); score += 0.2; } else { blockers.push({ field: 'state', detail: `Only for people in ${scheme.jurisdiction}`, gap: `${profile.state} is not ${scheme.jurisdiction}`, }); } } That comment is me explaining a bug I shipped. The first version compared jurisdiction strings. It worked for the local fixture, because ingest.ts writes All India for central schemes. Then the rows landed in Appwrite and a few came back with jurisdiction: Central and level: central. Every one of those schemes was rejected for a Telangana user, correctly spelled and completely wrong. level decides now. The string is decoration. The second rule is the one that keeps the tool honest: > A scheme is only rejected on a field it actually states. Every blocker carries a gap string the card prints verbatim. That is why a near miss reads "Your income, ₹2,40,000, is above the ₹1,00,000 ceiling" instead of "not eligible". The number is the product. People do not want a verdict, they want to know how far away they are. --- The join, and what the vector store is not allowed to hold export async function semanticCandidates(text: string, limit = 80): Promise<Hit[]> { const { vectors } = services(); const [vector] = await embed([text]); if (!vector) return []; const list = await vectors.listDocuments({ databaseId: VDB, collectionId: V_COLLECTION, queries: [Query.vectorCosine('embedding', vector), Query.limit(limit)], }); return (list.documents as unknown as Record<string, unknown>[]).map((doc) => ({ slug: String(doc.slug ?? doc.$id), similarity: readSimilarity(doc), })); } Eighty candidates by cosine similarity. Then the table layer runs its own predicate query, and the union of the two goes to the rules engine. Neither layer decides anything, which is the point: recall and truth are separate jobs, and the engine is the only thing allowed to say yes. !Illustration of Eligible A request looks like this end to end: semanticCandidates 80 tableCandidates 500 union 560 killedByRules 72 matched 488 total 95 ms Those are real numbers from the demo sentence on the real corpus, printed in the UI on every search. I would rather ship a receipt than a spinner. --- Four bugs worth writing down 1. Invalid query: Syntax error. The setup script passed queries: ['limit(1)'] and this SDK version wants Query.limit(1). The app code had it right; only the scripts were wrong. Half an hour lost to a raw string. 2. Cannot read properties of undefined (reading 'length'). ingest.ts writes a plain array of 2,066 schemes. The setup script expected { rows, embedText, meta }. Every schema statement succeeded, then the first row call read .length off undefined. The fix reads either shape, because a fixture format that changes should not look like a database outage. 3. Invalid document structure: Unknown attribute: "issuer". This one cost the whole load. Tables and indexes were created, then every batch failed and zero of 2,066 rows were saved. Appwrite validates a batch as one payload: one undeclared key rejects all hundred rows in it, and the error names whichever key it hit first, which is not the same as the list of things wrong. The fixture carries 28 fields, because the engine wants prose and clauses the table has no use for (issuer, embedText, eligibilityExcerpt, ageClause, incomeClause, genders). The table declares 23. The fix is projection, not schema growth: const payload = chunk.map((r) => ({ ...toRow(r as never), $id: String(r.slug) })); toRow() is now the only thing allowed to decide what a row looks like on the wire, and it drops every key the table does not declare. A second, quieter bug was hiding in the same function: it emitted documentsCount while the schema and the API read docsCount, so even a successful load would have shown a zero document count on every card. Neither bug tripped tsc, because both sides were typed as Record<string, unknown>. Schema drift is not a type error, it is a test you did not write. So: columns 23 rows 2066 violations 0 payload keys 23/23 missing [] extra [] max row 2741 bytes 4. A blank screen with a valid key. A project can be configured and empty. No tables, no rows, no vectors. The honest version of that state is a fallback that says so on the receipt: if (rows.length === 0 && hits.length === 0) { const result = searchLocal({ text, profile: merged, parsedBy }); result.receipts.vectorLayer = 'local fallback: Appwrite returned no rows (run npm run verify:appwrite)'; res.json(result); return; } A wrong key should degrade with a label, not a white page. --- The interface is the argument The first build looked like the last thing I shipped: rounded cards on warm paper with a green-and-saffron accent. Side by side with my earlier entry it read as the same product with different words, and it was rejected for exactly that reason. The rebuild starts from what the product actually is. Eligibility is not a marketplace listing, it is a document you are entitled to. So the page is a white sheet on a cool grey desk, divided by hairline rules instead of card borders, with a single red seal that appears only where a scheme was refused. Red is not decoration here. Red means no. Three decisions did most of the work: One seal, one meaning. --seal: #a32a1c is used for refusals, the "number that killed it" figure, and nothing else. The moment red also highlights a button, the refusal loses its weight. On the dark verdict band the same intent needs a lighter mix, #e2644f, because #a32a1c on #14181b measures 4.39:1 and fails AA. Two reds, two jobs. A bar drawn to scale. The answer opens with four bands: everything read, everything shortlisted by meaning, everything that passed, everything refused. They are sized in proportion, not as equal pills, so the refusal strip is visibly thin. 23.6% passed and 3.5% was refused, and you can see that before you read a word. Type set large on purpose. Newsreader for statements and amounts, Public Sans for controls and rows, both self-hosted variable woff2 files preloaded from public/fonts. 18px root, 52px submit button, 44px minimum on everything else. This is read on a phone at 9pm by someone who may be 60. The part I did not expect to matter was the placeholder. It sat at #8b959c on white, which is 3.05:1, technically fine for placeholder text and genuinely hard to read. It is #6b757c now, 4.71:1. The only reason I know that is that the audit prints numbers instead of opinions: const need = size >= 24 || (size >= 18.66 && bold) ? 3 : 4.5; const r = ratio(rgb(cs.color), bgOf(el)); if (r < need) low.push({ text, cls, ratio: r, need, size }); npm run audit drives Chrome at 1440, 1024 and 390 pixels, walks every label on the result screen, computes contrast against the actual painted background, measures every control, checks for horizontal overflow, and exits non-zero on any regression: 1440px overflow 0 sub-AA 0 targets<44 0 errors 0 bar 23.6/3.5% grid 148px 644px 128px 1024px overflow 0 sub-AA 0 targets<44 0 errors 0 bar 23.6/3.5% grid 148px 540px 128px 390px overflow 0 sub-AA 0 targets<44 0 errors 0 bar 23.6/3.5% grid 318px That is the whole design system, defended by a script instead of a screenshot. --- What it costs, honestly TablesDB on shared compute is free. VectorsDB needs dedicated compute, about $10/month, because an HNSW index keeps its graph in memory. The setup script creates the table layer first and the vector layer last, and if the project cannot host the second one it says so and leaves you a working app with lexical recall. The receipt then reads semantic: lexical. It never claims a vector search it did not run. That is the whole rule of the project. If the tool cannot do the thing, it says what it did instead. --- What I would build next - Deadlines. Most schemes open in windows. A closesOn column turns a search result into a calendar. - Follow up questions. "Two kids in school" should re-rank the list, not clear it. - Document checklists. The data knows how many documents a scheme needs. It does not yet know which ones. - Saved profiles. The profiles and searches tables are provisioned and barely used. A returning user should see what changed since last time. - Telugu and Hindi. The interface is the easy half; 2,066 cleaned summaries is the real work. Two databases, one question, and a receipt on every answer. That is the whole project. !How Eligible Looks Code & more: dailybuild.xyz

How I check Codex 5h and weekly limits across several accounts without opening a session I use more than one Codex account, each with its own `CODEX_HOME`, and wanted to see the 5h and weekly windows without starting a session in each one. So I built a small tray tool. How it works: - It reads `auth.json` from each `CODEX_HOME` and calls the usage endpoint with the existing token. It honors `chatgpt_base_url`. - It shows the 5h and weekly windows, extra limits and reset times in the macOS menu bar or the Windows tray. - It never refreshes tokens and never uses your limit resets. It only shows the count. - It's read-only. The one exception is "Make active", which you trigger yourself to switch the CLI's account. There's no telemetry and no backend. It handles Claude Code accounts too, if you use both. Caveat: the endpoint is undocumented. If it breaks, the app shows the last reading and how old it is. If you juggle multiple Codex accounts, how do you keep track today? I'd like to hear what's missing. Source (MIT): Abulkosim/margin

I got macOS Sequioa 15.8.1 to fully work on FX608JMR SUDO-PANIC6/Hachintosh-Fx608jmr

@yhlyjs @Macro_Zyaire 这个也还不错wanshuiyin/Auto-claude-code-research-in-sleep

DiscImageStudio: burn visible artwork onto CDs, DVDs and Blu-ray discs JiaFeiMiao-K-Cat/DiscImageStudio news.ycombinator.com

Switch - 原生开源 macOS 键盘窗口切换工具 列出所有空间中打开的窗口，输入即可筛选。 👉 Sanyam-G/switch t.co

YouTube: youtu.be サイト: unicode-frames.ikutotest.xyz ソースコード (MIT): ikuto32/unicode-frames

A quick note💛: gangfun/gang-launchpad we're buried in code all day. GitHub fills with new features — not every one ships. We argue until it sticks. Memecoin Launchpad gets rebuilt or we don't sleep. t.co

Minish Cap map scenes and a walking loop (game art by Nintendo/Capcom) A few Minish Cap scenes made with Minish Studio, a free fan editor I've been working on. I wanted a way to arrange the game's pixel art into little stories, from a simple walk through town to a Hyrule map full of encounters. The game artwork is by Nintendo/Capcom. The Hyrule atlas was mapped by rocktyt and shared on VGMaps; the illustrated map sheet is credited to Bacon on The Spriters Resource. The editor and scene arrangements are by SerakSan. You can change the characters and their poses, add dialogue, make sprite comics, or animate a scene with preset movements or a timeline. You can also import your own pictures and add pixel frames. It's a niche fan project, but hopefully a few people here enjoy making something with it :) Browser app: seraksan.github.io GitHub / offline download: SerakSan/minish-studio Original atlas: vgmaps.com Map sheet: spriters-resource.com All artwork sources and contributors: github.com/SerakSan/minish-studio/blob/main/CREDI… Unofficial fan project. Your scenes stay on your device; animation still has a few rough edges.

@theodorvaryag Take a look at dynamic derivations, repkgs and quality-forks/mix

@gilles_pilloud @charleshallard Le projet qu'il te faut : f00b4r0/tic2json

Show HN: Bitcoin-rs – An independent Bitcoin full node in Rust

CPUだけで動くTransformerベースのかな漢字変換IME : fcitx5-slm-ime 作ったもの CPUだけで動くcharacter-level Transformerベースのかな漢字変換IMEを作成しました。 oogasawa/fcitx5-slm-ime モデルは約 6000 万パラメータと小さいので、普通のノートPCやミニPCのCPUで快適に動きます。これを動かすためにGPUは必要ありません。現状Linuxデスクトップ上のかな漢字変換IMEとしてfcitx5の上で動きます。 従来の日本語入力メソッドは、まず入力されたひらがなを形態素解析で文節に切り分け、その切り分けを使って漢字を選びます。しかし正しい切り分けには文全体の意味の理解が必要であり、文全体の意味の理解には正しい切り分けが必要という循環依存がありました。 Transformerを直接使えばこの循環依存が起こりません。別個の形態素解析器はありません。そこでこれを使ってIMEを作成してみました。その際の課題は動作速度です。高額なGPUを使わないと実用の速度にならないとすると活用の場が限られてしまいます。そこで極力小さいTransformer (Small language model)でこれを実現してみたところCPUだけで実用上問題ない速さで動くことが確認できました。 下の動画は入力の様子です。ごく普通のかな漢字変換IMEの操作方法で使えます。 入力されたひらがなから、言語モデルが漢字かな交じり文を文節の境界と一緒に一発で書き出します。 書き出された漢字仮名交じり文を修正する際には仕組みとしてAnthyを使っています。修正する用途としてプログラムが完成されておりこの目的に対して完璧に動作するからです。 変換精度の評価 Linuxデスクトップで広く使われるAnthy, Mozcと変換精度を簡単に比較してみました。技術用語が多い長文を一括で入力すると既存の方法に対して性能差が顕著になることがわかります。例えばWikipedia日本語版の内容だと60文字程度のひらがなに対してfcitx5-slm-imeは44%で変換結果の修正を必要としません。(Mozcでは23%, Anthyでは4%。詳細は githubのREADMEを参照。） ダウンロード インストール方法の詳細はgithubのREADMEを参照下さい。 ソースコード（Apache License 2.0）: oogasawa/fcitx5-slm-ime パッケージと学習済みモデル（2.1.0）: github.com/oogasawa/fcitx5-slm-ime/releases/tag/v… Debian 13 と Ubuntu 24.04 向けの fcitx5-slm-ime（amd64、arm64） Fedora 44 向けの fcitx5-slm-ime（x86_64） モデルの slm-ime-model（.deb、.rpm）と、ソースからインストールするときに使う slm-ime-model-2.1.0.tar.gz（slm-ime-weights.bin と tokenizer.json、CC BY-SA 4.0） Fedora の COPR（Fedora 43、44、45、Rawhide の x86_64 と aarch64）: copr.fedorainfracloud.org 学習データ（読みと文の組、490 万組、CC BY-SA 4.0）: huggingface.co バージョン 1（モデルを PyTorch と DJL で、Java のサーバーで計算する版）: ブランチ 1.x（github.com/oogasawa/fcitx5-slm-ime/tree/1.x）、リリース 1.3.0（github.com/oogasawa/fcitx5-slm-ime/releases/tag/v…）

Huge props to hyprwm for the rock-solid architecture and buttery smooth animations on this one. That dynamic tiling workflow is seriously next-level. ⚡️ 🔗 项目地址：hyprwm/Hyprland

Formal Web: a modular Web engine written in Rust and using formal methods Reposting; this time with a focus on why it is not a code dump. The project I would like present is a web engine written in Rust. It does not break new grounds in the sense of being the first Web engine in Rust, because we have had a Web engine for a long time, where I am myself involved as a maintainer and Technical Steering Committee member: Servo. However, this is not a code dump either, because: - Myself, and others, have been working on this since March of this year. - This post is a "full fledged post", which is supported by a linked-to longer essay (see below) - I will below explain the relevance for the Rust community - I will compare it with other Web engines written in Rust. ---- Ok so now that this is out of the way, here is the actual post: gterzian/formal-web is a new prototype of a Web engine written in Rust. It is relevant for the Rust community, because it provides us with something new: - a multi-process graphics stack based on modern Rust components, like Vello and Wgpu, paired with a modular design allowing deeper platform integration, for example integrating with Core Animation and using IOSurface on Apple platforms. - A modular approach to integrating a Javascript engine, so that you can "bring your own engine". Currently V8 and the all Rust Boa are supported out of the box, and other engines, Like the also all Rust Nova, could be integrated through the implementation of various traits. - Use of Blitz components, blitz-dom and blitz-paint, as a kind of DOM engine inside the Web engine. - Use of formal methods to model check multi-process Rust code, based on the approach described at Validating Traces of Distributed Programs Against TLA+ Specifications - Modularity of various other layers, such as: networking, media, and the starting of and communication with process-like sub-components. - An embedder API that makes it easy to do various platform specific integrations, such as using a display link on Mac. - An explicit goal of eventually being able to Ship on IOS in the EU as per Apple's guidelines. How is this different from other Web engines in the Rust ecosystem? Difference with Servo: the graphics stack of Servo does not isolate GPU operations in a dedicated process and it is based on an OpenGL stack. Difference with Blitz: while Blitz does integrate well with Vello/Wgpu, it is not designed around process isolation of either GPU operations or the running of Javascript, making it less suitable for the Web use-case where you essentially run untrusted code downloaded over the internet. While it does use Anyrender as modular render target, it does not offer modularity at the lower-level end of the graphics pipeline. Neither engines allow swapping out JS engines, and neither allow for deep platform graphics integration like Core Animation based compositing on Mac (which can make a large difference in terms of battery life). For a walk-through of the entire flow involved in rendering a frame of Web content, see the introduction essay: How I am building a Web engine. The essay also contains a gif showing the benefits of Core Animation on Mac, where only relevant parts of the screen are re-rendered. Please let me know what you think. I can also use help implementing countless Web standards.

700+ AI Video Prompts You Can Copy for FREE! 🤯 #aitools #claude #motion #Graphics #Animations 💀 Is AI changing the future of motion design? Imagine creating stunning animations, 3D visuals, cinematic videos, and motion graphics using AI prompts you can simply copy, customize, and recreate! Meet Awesome Opus 5.5 Videos — an incredible open-source GitHub repository featuring hundreds of AI-generated video examples and their original prompts. 🔥 What will you discover? 🎬 Motion Graphics & Typography ✨ 3D Visuals & Animations 🚀 Cinematic AI Videos 📺 Explainer Videos 🎮 Interactive Experiences 💡 Creative Video Concepts The best part? You can explore the prompts, learn how these animations were created, and use them as inspiration for your own projects. 📌 GitHub Repository: yihui-dev/awesome-opus5-5-videos Want more hidden GitHub gems, AI tools, and creative resources? 💬 Comment "MOTION" below! 📌 Save this video for your next creative project. Follow ApexNucleus for more AI tools, automation hacks, and digital innovation. 🌐 Website: apexnucleus.com 📸 Instagram: instagram.com #ClaudeAI #Opus55 #MotionDesign #AIAnimation #GitHub #AITools #MotionGraphics #CreativeAI #3DAnimation #VideoEditing #AIVideoGeneration #OpenSource #AICreators #ApexNucleus

Very excited about this!! Built a narrow version of this for the company I'm working at and been using it to verify all kind of workflows. It has virtual time too! It's such an unlock for merge confidence. karthiksraju/workflow-sim

RagLeap Ansible and Terraform Resources Are Now Available for Java Two new Maven Central releases package RagLeap's existing infrastructure files for Java applications. RagLeap has published two new Java artifacts: - ragleap-ansible 0.1.2 - ragleap-terraform 0.1.1 Both are available through Maven Central. These releases are designed for Java developers who want to read RagLeap's existing infrastructure resources from a Java application. One important clarification: These are resource-packaging releases, not Java ports of Ansible or Terraform. The JARs contain the same six files distributed through the corresponding PyPI wheels. They provide small Java classes for reading those resources from the classpath. Ansible and Terraform are not included or executed by the JARs. Why package these resources for Java? RagLeap is an open-source, self-hosted AI infrastructure ecosystem. Its infrastructure packages include Ansible resources and Terraform modules. These are useful beyond the Python application itself, so I wanted to make the existing files accessible from Java projects too. Rather than rewriting the resources in Java, the releases package the original files. This gives Java applications a simple way to access them while keeping the Python distributions as the matching resource source. 1. RagLeap Ansible Java 0.1.2 Maven coordinates: <dependency> <groupId>io.github.antonyrag</groupId> <artifactId>ragleap-ansible</artifactId> <version>0.1.2</version> </dependency> Release: github.com/ragleap/ragleap-core/releases/tag/ragl… Maven Central: central.sonatype.com PyPI: pypi.org Included resources The JAR contains the six files from the PyPI wheel, including: playbooks/bootstrap.yml The Java resource reader is: com.ragleap.ansible.RagleapAnsible It provides: openPlaybook(path) and: readPlaybookString(path) Example: import com.ragleap.ansible.RagleapAnsible; public class Example { public static void main(String[] args) throws Exception { String playbook = RagleapAnsible.readPlaybookString("bootstrap.yml"); System.out.println(playbook); } } The path is resolved under the packaged playbooks/ tree. Paths must be relative. Backslashes and parent-directory traversal are rejected. Ansible execution is not included This Java artifact only reads the packaged playbook resources. It does not: - Include Ansible. - Run playbooks. - Start processes. - Connect to remote hosts. - Change infrastructure. You still need Ansible separately if you want to execute the playbooks. 2. RagLeap Terraform Java 0.1.1 Maven coordinates: <dependency> <groupId>io.github.antonyrag</groupId> <artifactId>ragleap-terraform</artifactId> <version>0.1.1</version> </dependency> Release: github.com/ragleap/ragleap-core/releases/tag/ragl… Maven Central: central.sonatype.com PyPI: pypi.org Included resources The JAR contains the six Terraform files from the corresponding PyPI wheel: modules/kind-cluster/main.tf modules/kind-cluster/variables.tf modules/kind-cluster/outputs.tf modules/kind-cluster/versions.tf examples/kind/main.tf examples/kind/.terraform.lock.hcl The resource reader is: com.ragleap.terraform.RagleapTerraform It provides: open(...) and: readString(...) Example: import com.ragleap.terraform.RagleapTerraform; public class Example { public static void main(String[] args) throws Exception { String module = RagleapTerraform.readString( "modules/kind-cluster/main.tf" ); System.out.println(module); } } The resource is read from the JAR's classpath. Terraform execution is not included The Java artifact does not include Terraform or execute Terraform commands. The current packaged module creates a local kind cluster. Cloud modules are not included yet. The module's actual application remains a Terraform responsibility. 3. Resource parity: the important part Both Java releases package the same files as their corresponding Python distributions. That was verified through file-list and file-content comparisons. The six files in each published JAR were compared byte for byte against the matching PyPI wheel. The result: - Ansible Java 0.1.2: six matching resource files. - Terraform Java 0.1.1: six matching resource files. This is the main design goal. The Java artifacts should not become a separate version of the infrastructure resources. Keeping the packaged files identical reduces the chance of Java and Python distributions drifting apart. 4. Published artifact verification Both releases were built from: e5e4328837758a03cb21e1207c8aec90a88b5c87 Build environment: OpenJDK 21.0.12 Maven 3.6.3 Build command: mvn -Prelease clean deploy The JAR, sources JAR, Javadoc JAR, and POM were signed. All four signatures were verified before upload. After publication, the JARs served by Maven Central were checked against the locally built artifacts. Ansible 0.1.2 Published JAR SHA-256: 1e33f98f9f4bea29763686fec4de97aad6bbc14e1447d1a4a958917062319cf4 The published JAR matched the locally built JAR. Its signature verified with the same key. Central listed 24 files for the release. Terraform 0.1.1 Published JAR SHA-256: a73b1030f79c6827a7afc8689b986e2ca929cdc7097e6f2e1b4f6557f127a354 The published JAR matched the locally built JAR. Its signature verified with the same key. Central listed 24 files for the release. These checks cover the published artifact, checksum, signature, and resource parity. 5. CI checks The Ansible resource-parity workflow passed on main and on the pull request. The Terraform resource-parity check passed on main. The workflows compare the packaged file list and contents against the corresponding Python wheel. The infrastructure execution tests remain in the Python package test suites: - Ansible: container idempotence and real-host tests on GitHub-hosted Ubuntu 22.04 and 24.04. - Terraform: live apply and destroy testing on a real kind cluster. Those tests were not repeated by the Java JAR releases. 6. What is not tested yet? The published JARs were not built into a separate consuming Java project. Other JDK and Maven versions were not tested. The JARs only package resources. They do not provide an execution environment for Ansible or Terraform. So the current verification should not be interpreted as a claim that Java applications can execute infrastructure automation directly through these artifacts. The releases are intentionally limited to resource access. 7. Try the releases Ansible Java <dependency> <groupId>io.github.antonyrag</groupId> <artifactId>ragleap-ansible</artifactId> <version>0.1.2</version> </dependency> - Maven Central - GitHub release - PyPI package Terraform Java <dependency> <groupId>io.github.antonyrag</groupId> <artifactId>ragleap-terraform</artifactId> <version>0.1.1</version> </dependency> - Maven Central - GitHub release - PyPI package RagLeap Core ragleap/ragleap-core Final note These releases are a small but practical step toward making RagLeap's infrastructure resources easier to use across language ecosystems. The goal is not to replace Ansible or Terraform with Java. The goal is to let Java applications access the same infrastructure resources that RagLeap already distributes through Python—while keeping the package boundaries clear and the verification claims honest. More open-source infrastructure work is ongoing.

MIT, developer preview, breaking changes expected. Would you let an agent install code into your own dev tool? npx @deepseek-ai/dsh web deepseek-ai/deepseek-harness

computer-repair-skill 给 Codex、Claude Code 等 Agent 配了 64 套电脑维修流程，直接描述故障，就能按步骤查系统、看日志、找原因。 电脑卡顿、没声音、连不上网，以及应用迁移、数据恢复都有对应流程，覆盖 Windows、macOS 和 Linux。 GitHub：88lin/computer-repair-skill 我比较认可它先查再改的做法。检查时先读系统状态，涉及删除、重启、分区这些操作，会列出影响和恢复方案，确认后再动手。 查磁盘空间时，还会继续往大文件夹里找，区分能重新生成的缓存、代码仓库数据和模型文件，清理后核对实际释放的空间。 装成 Skill 就能用，不需要另外装桌面软件或接专用云服务。查什么问题才读对应的维修流程，不会一次塞入整套手册。

Try it: npx @deepseek-ai/dsh web deepseek-ai/deepseek-harness

Soulcalibur 2 with all console exclusive characters tmcleroy/soulcalibur2-recomp I made a native recomp (PC, Mac, Linux) of the Xbox version of SC2 and ported in the console exclusive chars from the GC and PS2 versions (Link and Hehachi), they're all playable in the same game now. This is playable with only the Xbox ISO but you have to have ISOs for all 3 versions of the game if you want to play all the console exclusive chars, of course no game data is included in the repo. It includes the extra features I like to add in my other fighting game recomps like online play with rollback netcode, better training mode features, and free camera mode. See the repo readme for details. As always contributions and issue reports are welcome, have fun!

本地跑大模型的引擎，今天又来一个更极端的： colibri 纯 C、零依赖 专家权重从硬盘流式读，744B 参数的 GLM-5.2 在 CPU 上 32 秒就绪、常驻内存不到 10GB。 没有显卡也能跑前沿 MoE 模型，8GB 内存的机器就能起步。 #AI #本地部署 JustVugg/colibri

There are developers who know terminal commands. And then there are developers who make the terminal look like a superpower. This repo teaches practical shell tricks, command-line workflows, and debugging techniques. jlevy/the-art-of-command-line

I made a web app to identify photos I don't have in immich yet, then either import them or upgrade existing assets with their metadata intact I made this for myself, but figured someone out there might find it useful! I keep finding folders of old phone backups, Takeouts and Flickr exports on my NAS with little idea what I already have in immich, or (horror of all horrors) if I was about to delete a better quality copy. The anxiety was all getting a bit much, so I built Immich PhotoCopy to make sorting through the mess a whole lot easier. Feed it an API key and point it at a folder, it'll show you thumbnails of the contents split into: - Not in immich: no exact copy found anywhere in your account - Filename match: same name, different file (full-res original vs. a compressed/downscaled copy etc.) - In immich: byte-identical copy found, safe to nuke into oblivion Works with multiple accounts, handy if (like me) you use several external-libraries. Then you can: - Upload missing photos, tagged so they're easy to find or undo later, optionally creating albums from folders - Upgrade filename matches in-place, with the new photo inheriting the old asset's albums, tags, favourite and description - Copy/move files elsewhere, or recycle loose files once they're confirmed safely in immich - Identify damaged files, JPEGs that don't decode properly are flagged and never uploaded Safety first! - It reads immich's database with a read-only Postgres role and can't write to it - Nothing is ever hard-deleted - removals go to the share's recycle bin via multiple bright red confirmation dialogs It's a single Docker container, built and tested on a UGREEN DXP4800 Plus with immich 3.3.5. Untested on Synology or other Docker host, but should probably work. Disclaimer: Not affiliated with immich, read the docs use at your own risk and keep backups! Grab it on GitHub: triffski/tr_immich_photocopy Feedback and bug reports welcome! Ish.

[For Hire] [Remote] [Worldwide] - Senior Backend & Applied AI Engineer (8+ YOE) | Java (Spring Boot), Python (LangGraph/MCP/RAG), Kafka, K8s, Distributed Systems I am a Senior Software Engineer with 8+ years of total software engineering experience (including a Master of Science in Computer Science from the University of Florida). I specialize in architecting high-throughput distributed backend systems, enterprise micro services, and production GenAI/agentic infrastructure. My work spans building zero-downtime event-driven pipelines, optimizing database query performance under high concurrency, and transitioning AI prototypes into resilient, production-grade agentic workflows (RAG, tool-calling via MCP, and custom vector search engines). Core Stack - Backend & Distributed Systems: Java (17/21), Spring Boot, Spring Security, Python (FastAPI), Apache Kafka, RESTful APIs, gRPC, Micro services Architecture - AI & Agentic Infrastructure: LangGraph, LangChain, Model Context Protocol (MCP), RAG, PyTorch, Vector Search (Qdrant, Milvus, PGVector), Spring AI, vLLM/Ollama - Databases & Caching: PostgreSQL, MySQL, MongoDB (Aggregation Pipelines & Document Modeling), Redis (LRU Caching), Elastic search (ELK Stack) - Cloud & DevOps: AWS (EKS, EC2, S3, SQS, Lambda), Docker, Kubernetes (K8s), Terraform, CI/CD pipelines, Git - Testing & Quality: JUnit, Mockito, PyTest, Test-Driven Development (TDD), Domain-Driven Design (DDD), Root Cause Analysis (RCA) Key Technical Achievements & Projects - High-Throughput Micro services & Scaling (Remora): Architected and containerized Java 17 micro services on AWS Kubernetes (EKS) with Kafka event streams, driving a 30% system performance improvement and supporting a 50% expansion in enterprise client capacity. - Agentic AI & RAG Engine: Built production-grade agentic workflows using Python, LangGraph, Spring AI, and vector databases. Implemented secure Model Context Protocol (MCP) integrations using tool-calling for automated document processing and log analysis. - Audit & JSON-Diff Compliance Platform: Engineered a real-time audit system using Spring Security and MongoDB paired with an admin UI featuring dynamic JSON-diffing to track complex entity modifications across enterprise clients. - Legacy Persistence & Query Optimization (Itiviti & Verdantis): Optimized MongoDB aggregation pipelines and custom Java LRU caching to cut query latency by 7% on financial analytics streams. Architected data ingestion layers yielding a 300% boost in payload processing efficiency. Availability & Logistics - Location: Mumbai, India (Open for 100% Remote Global Roles) - Timezone: IST (UTC+5:30) — Flexible overlap with US (EST/PST), EU/UK, and APAC working hours - Role Types: Full-Time, Contract, or B2B Technical Contracting - GitHub:github.com/skushal746 - LinkedIn:linkedin.com - Email: [skushal746@gmail.com](mailto:skushal746@gmail.com)

BBS Gateway I have released an alpha version of my BBS Gateway software. Please, roast and praise away! I would love to know what people think about it. BTW, I'm a Sysop as well. I'm going to start dabbling in the creation of modern utils and doors. This can be used as a front end or a door to connect to outbound systems. Please give it a try! System Architecture & Key Features serverhand/BBS-Gateway - Handle Port 23 Telnet negotiations in bbs_gateway.py by sending IAC WILL ECHO, IAC WILL SGA, and IAC DO BINARY (Mystic v1.10 Telnet Notes) so BBS terminal clients (SyncTERM, NetRunner, mTelnet, PuTTY) enter unbuffered character-at-a-time CP437 mode automatically. - Render gateway.ans and the interactive lightbar with automatic SAUCE metadata stripping, Mystic pipe color support (|00–|23), and three selectable display modes in gateway.cfg: - BOTH displays gateway.ans as the background frame and overlays the interactive arrow-key lightbar selector at (MENU_START_X, MENU_START_Y). - LIGHTBAR draws a self-contained ANSI frame with the interactive lightbar selector even if gateway.ans is absent. - ANSI_HOTKEY displays gateway.ans full-screen and waits for single-key hotkey entry (1–9, A–Z, or L to toggle the lightbar). - Proxy local and external BBS connections bidirectionally over raw TCP (127.0.0.1, LAN IPs like 192.168.1.50, or external domains like agency.bbs.nz:23), including an on-demand [P] Ping check that tests live latency (UP XXms / OFFLINE) across all listed boards. - Manage listings inside Mystic BBS using gwconfig.mps, which uses Mystic's MPL file and screen routines (fAssign, fReset, fReWrite, WriteXYPipe, Input, and AllowArrow) so the SysOp can add, edit, delete, and reorder BBS entries or customize lightbar coordinates, timeouts, and colors directly from a Mystic menu. - Store settings in human-readable format inside gateway.cfg using KEY = VALUE pairs and pipe-delimited BBS = Hotkey | Name | Host | Port | Scope | Description rows that both bbs_gateway.py and gwconfig.mps read and write without needing a restart. Install: git clone serverhand/BBS-Gateway

Got a big polish pass into Overlook tonight, cleaning up the menu bars, the padding, and tightening up the UI quite a bit. It's really coming together! Amazing email/calendar client for Omarchy! Repo: last-refuge/overlook t.co

伸びてるので宣伝させてけろ！ わしが開発しとるPDFライブラリじゃ。あと少しで5Kスター行くからスターくれ！ pdfme/pdfme

Running 100B Models at Home: the Disk Is the Limit, Not the GPU Anton wants a deep research piece, something like a journalistic investigation: how an ordinary person can get access to large LLMs, 60 to 100 billion parameters and up, without hard restrictions or censorship. The ones that discuss any topic, including dangerous ones. He wants to understand what models exist at all, LLaMA-like, Chinese and not Chinese, open-source; which can be stood up at home from Hugging Face; which can realistically be run without buying a new graphics card; where to rent a GPU or a server and deploy a model there; whether there are services where such a model already sits and you can simply pay per token; and who uses these models and for what. His own framing closes it: what interests him is not instructions but how available such models actually are, and what the ecosystem around them looks like. Four measurements change the question. First, and it is the one that matters: the machine is already on his desk. The thing that runs a 60 to 100 billion parameter model without a new graphics card is a Mac with a lot of unified memory, and he bought one on 27 October. His own words that day: 128 gigabytes of RAM, the second Mac setting it up over SSH. For this class of model, 128 gigabytes of unified memory is the configuration people name as the sweet spot: one source calls it the best overall pick for models up to 120B, another the only sub-$10,000 option that runs 70B-class models entirely in fast memory. He has it. The research question "which can I realistically run without buying a GPU" was answered by a purchase six days ago. Second, the real constraint is not the card, it is the disk, and he wrote that down himself. In the same post on 27 October: he bought the Mac with 512 gigabytes of storage, could not migrate from the laptop because of it, and said plainly that the disk is not enough. Now put the model weights next to that number. A 100B model at 4-bit quantisation is roughly 50 gigabytes of weights; at 8-bit it is about 100. Measured examples on a 128GB Studio: gpt-oss-120b in MLX occupies 64 GB, a 4-bit Qwen3.5-122B-A10B occupies 69.6 GB. So two or three such models, plus macOS, plus his vault, and the 512 gigabytes are gone. The honest version of his question is not "can I run it" but "where do the weights live", and the answer is the external Thunderbolt drive he already said he needs to buy urgently. ⚠️ One more hardware detail that bites before any of this: by default macOS caps what the GPU may allocate, often around 75% of total RAM. On 128 gigabytes that is roughly 96, which makes a 120B model tight rather than comfortable. The cap can reportedly be raised by hand, which is a thing to know before concluding the machine cannot do it. Third, his size bracket is no longer the top of the market, it is the middle. He asks about 60 to 100 billion and up. In 2026 the largest open-weight releases are an order of magnitude past that, and they are Chinese: one analysis of the Hub puts the biggest open model released by a Chinese lab each month between January and August 2026 at 754 billion to 2.78 trillion parameters. DeepSeek V4 Pro is listed at 2.4 trillion total with about 95 billion active per token; Moonshot's Kimi at 2.8 trillion total and 104 billion active; Mistral Large 3 at 675B total and 41B active. Llama's Behemoth was never shipped publicly and is widely treated as shelved. That active-parameter number is the trap, and it is worth being precise about. A model with 95 billion active parameters is not a 95 billion parameter model you can hold in memory. You store all the weights and only compute with a fraction. Which is why "60 to 100 billion" sounds like the trillion-class models are within reach when they are not, and also why the mixture-of-experts ones that do fit run surprisingly fast: fewer weights read per token. One source measures gpt-oss-120b at 87.9 tokens per second on a 128GB M5 Max against roughly 20 to 35 for a dense 70B. Fourth, paying per token already exists and costs almost nothing. A catalogue snapshot from August 2026 lists an uncensored open-weights model, from the Mistral family, at $0.20 input and $0.90 output per million tokens with a 128K context, and a free variant with a 32K context. OpenRouter is reported to pass provider rates through with no per-token markup, adding only a 5.5% fee on credit purchases; free models carry rate limits of 50 requests a day, rising to 1,000 with $10 or more in credits. ⚠️ These are third-party aggregator figures and can lag or misreport, so the live /models page is the check before relying on them. On renting a GPU, the direction of travel is against him. October 2026 figures: Lambda's 8-GPU H100 SXM at $3.99 per GPU-hour, up from $2.99 in 2025; RunPod Secure Cloud H100 SXM from $3.29 to $3.99, with Community Cloud at $1.99 to $2.69; Vast.ai, being a marketplace, from $1.33 with a median around $2.00. A100 80GB is cheaper, around $1.29 on RunPod and $0.70 to $1.05 on Vast.ai. SemiAnalysis is reported to have tracked one-year H100 contracts rising almost 40%, from $1.70 per GPU-hour in October 2025 to $2.35 by March 2026. ⚠️ The sources disagree badly with each other, one March article listing RunPod's H100 at $2.39 against the October figure of $3.99, so every one of these needs the provider's own page before it means anything. And the quiet finding that actually answers "which ones are open-source". A 2026 study found that 95.8% of models on the Hub lack the licence text their permissive label implies, and only 3.2% met both requirements. So the label on the model card is not the licence, in the overwhelming majority of cases. Separately, gating is per-model and inconsistent even within one vendor: a licence audit found Black Forest Labs shipping two FLUX.2 models on the same day, one ungated under Apache-2.0 and one gated under a non-commercial licence, and Hub gating approves individual users, not organisations. One number reframes the whole investigation. On the Hub, models under 1 billion parameters take 83% of all-time downloads, and everything above 100 billion takes 1%. Availability and use are not the same thing. The ecosystem he is asking about exists, it is cheap to rent and cheaper to call per token, and almost nobody is using the big end of it. That, rather than any question of restrictions, is the thing worth explaining in the research. So the research brief that pays off is narrower than the one he dictated. Not "what exists", which is mostly catalogued already. Rather: what fits in 128 gigabytes of unified memory at what quantisation and what speed; what the weights cost in disk, which is his actual bottleneck; what per-token hosting costs for the same model class, so renting can be compared against running; and which licences are real rather than labelled. Four answerable questions instead of six open ones, and the hardware half of it he can measure himself this week on a machine he already owns. The full story, in two versions: 📖 For humans, the longread: github.com/tonydzi/clawrush/blob/main/longreads/2… 🤖 For machines, the devlog: github.com/tonydzi/clawrush/blob/main/devlog/2026…. Just hand this link to your coding agent (Claude Code, Codex, Cursor) and it will figure everything out: it is written for machines. 🔗 All our channels and contacts in one place: linktr.ee Invented by Mycroft and Tony Dzi (Anton Dziatkovskii), Palo Alto AI Research Lab. Proudly made in Silicon Valley.

PostgreSQL 14 End of Life on 12 November 2026: How to Upgrade Postgres in Docker PostgreSQL 14 gets its last update on 12 November 2026. The PostgreSQL versioning policy lists that date as the final release for version 14, and the rule behind it is short: each major version is supported for five years, then it gets one final minor release and becomes unsupported. Any security bug found in 14 after that day stays unfixed. The calendar around it is tight. The PostgreSQL 19 RC 1 announcement of 15 October says the 12 November update release "will include a large number of fixes", and it puts general availability of PostgreSQL 19 on 19 November 2026, one week after 14 drops out of support. If you are still on 14, you have to choose a target now, before 19 has any track record. Managed databases get a little more room. The Amazon RDS for PostgreSQL release calendar keeps 14 in standard support until 28 February 2027, with paid Extended Support starting on 1 March 2027. A self-hosted container gets no grace period at all. The postgres:14 image you pulled in 2022 keeps running exactly the code it shipped with. Why so many stacks are still on 14 Postgres is the line in a compose file people are most nervous about touching, and with reason. Changing the image tag across a major version does not upgrade the data, because the on-disk format changes between majors. The versioning page says it plainly: a dump/reload or pg_upgrade is required. So a stack set up in 2021 or 2022 tends to get its app images rebuilt every month while the database tag sits still. The official Docker image moves on regardless. The versions.json file in the docker-library/postgres repository, which lists the versions the image maintainers build, currently covers 14 through 19. PostgreSQL 13, which reached end of life in November 2025, is no longer in it. Step 1: find every Postgres 14 you run Image names are not reliable. A container may run PostGIS, TimescaleDB, a vendor image or something built in-house, all with Postgres inside. Ask the binary instead: {% raw %} for c in $(docker ps --format '{{.Names}}'); do v=$(docker exec "$c" postgres --version 2>/dev/null) && echo "$c: $v" done {% endraw %} That only sees running containers, so also search compose files on disk for stacks that are stopped or live on other hosts: grep -rnE 'image: *"?postgres' --include='*compose*.y*ml' /srv /opt 2>/dev/null For every 14 instance, write down three facts before planning anything. Each one decides a step later on (examples below use a container called pg14): {% raw %} # data checksums: "version: 0" means off docker exec -u postgres pg14 pg_controldata | grep -i checksum # bootstrap superuser: empty output means "postgres" docker exec pg14 printenv POSTGRES_USER # where the data volume is mounted docker inspect -f '{{range .Mounts}}{{.Source}} -> {{.Destination}}{{"\n"}}{{end}}' pg14 {% endraw %} Step 2: pick the target version Our recommendation is PostgreSQL 18, not 19. Version 18 is the current stable line (18.6 on the versioning page today) and is supported until 14 November 2030. 19.0 will be a week old when 14 expires, and a migration forced by an end-of-life date is a poor moment to also be an early adopter. Move to 18 now and plan 19 for next year, once a few minor releases are out. You do not need to step through 15, 16 and 17. The pg_upgrade documentation says it supports upgrades "from 9.2.X and later", and the versioning page confirms you can skip versions, while recommending that you read the release notes of every version in between. For 14 to 18 that means the notes for 15, 16, 17 and 18, starting with the incompatibilities list at the top of each. Step 3: take a backup you have restored once docker exec pg14 pg_dumpall -U app | gzip > pg14-$(date +%F).sql.gz Restore it into a scratch container and run a few queries against it. Until you have done that, it is a file, not a backup. Option A: dump and restore For databases up to a few gigabytes this is the simplest path, and it clears out table bloat as a side effect. Start a postgres:18 container next to the old one with its own empty volume, then stream the data across: docker exec pg14 pg_dumpall -U app | docker exec -i pg18 psql -U app -q When we ran this, psql printed two errors: ERROR: role "app" already exists ERROR: database "app" already exists Both are harmless. The new container created that role and database on first start, and the rest of the dump loads into them. The cost of this method is downtime: writes have to stop for the whole dump and restore, so it grows with the size of the data. Option B: pg_upgrade with hard links For larger databases, pg_upgrade --link recreates the schema in the new cluster and hard-links the data files instead of copying them. The pg_upgrade documentation says link mode is "much faster (no file copying)" and uses less disk space. It needs the binaries of both versions in one place, which the official image does not provide. The tianon/docker-postgres-upgrade project publishes images tagged OLD-to-NEW, including 14-to-18. Its README calls it a proof of concept to "learn from" and adapt, not a finished tool, and that matches what we saw. We upgraded a throwaway 14.24 cluster created with POSTGRES_USER=app, which is how most compose files set it up, to 18.6. It failed three times before it worked, and none of the three is specific to our setup. Error 1: data checksums old cluster does not use data checksums but the new one does Failure, exiting The PostgreSQL 18 release notes list this under incompatibilities: initdb now enables data checksums by default, and "pg_upgrade requires matching cluster checksum settings". A cluster created by the postgres:14 image has checksums off unless you asked for them. The fix is to create the new cluster with --no-data-checksums. If you want checksums, turn them on afterwards with pg_checksums on the stopped cluster. Its documentation warns that on a large cluster this "can potentially take a long time", and nothing else may write to the data directory while it runs. Error 2: the superuser name FATAL: role "postgres" does not exist could not connect to source postmaster started with the command: ... The helper image runs initdb as the default postgres superuser and connects to the old cluster with that name. If your compose file set POSTGRES_USER=app, the old cluster has no role called postgres. Pass the real name to both initdb and pg_upgrade. With both fixes in place, run the check mode first. It changes no data: # old cluster stopped, its files moved to /srv/pg/14/docker docker run --rm \ --mount type=bind,src=/srv/pg,dst=/var/lib/postgresql \ -e PGDATAOLD=/var/lib/postgresql/14/docker \ -e PGDATANEW=/var/lib/postgresql/18/docker \ -e POSTGRES_INITDB_ARGS='--no-data-checksums --username=app' \ tianon/postgres-upgrade:14-to-18 --check --username=app When it prints *Clusters are compatible*, run the same command with --link --username=app in place of --check --username=app. Error 3: the app can no longer connect The upgrade finished and postgres:18 started on the new data. Then a client in another container got this: FATAL: no pg_hba.conf entry for host "172.26.0.3", user "app", database "app", no encryption The official image adds a line to pg_hba.conf that allows password logins from other hosts, but only when it initializes an empty data directory. Here initdb ran inside the helper image, so the new pg_hba.conf only trusts local connections. The pg_upgrade documentation warns about this in its "Restore pg_hba.conf" step and adds that postgresql.conf and postgresql.auto.conf may need the same treatment. Copy your old files over if you changed them. If you only had the image defaults, add the line back: docker exec pg18 sh -c 'echo "host all all all scram-sha-256" >> "$PGDATA/pg_hba.conf"' docker exec pg18 psql -U app -c 'SELECT pg_reload_conf()' The volume path changed in the 18 image Starting with 18, the official image keeps data in a version-specific directory, /var/lib/postgresql/18/docker, and declares its volume at /var/lib/postgresql. The image documentation says mounts should target the new location, and pull request #1259 explains why: with one mount for both versions, pg_upgrade --link works without crossing filesystems. Update the service definition to match: db: image: postgres:18 volumes: - /srv/pg:/var/lib/postgresql # not /var/lib/postgresql/data If you just change the tag and leave the old mount, the 18 entrypoint script refuses to start and prints: Error: in 18+, these Docker images are configured to store database data in a format which is compatible with "pg_ctlcluster" ... That is a safe failure. It is still better to see it in a test run than at 2 a.m. After the upgrade PostgreSQL 18's pg_upgrade keeps optimizer statistics, according to its release notes, but our run still ended with "Some statistics are not transferred by pg_upgrade" and suggested two vacuumdb commands. Run them, then look for passwords stored as MD5: docker exec pg18 vacuumdb -U app --all --analyze-in-stages --missing-stats-only docker exec pg18 vacuumdb -U app --all --analyze-only docker exec pg18 psql -U app -Atc "SELECT rolname FROM pg_authid WHERE rolpassword LIKE 'md5%'" The PostgreSQL 14 release notes switched the default password hashing to SCRAM-SHA-256, but roles carried over from 13 or older can still hold MD5 hashes. PostgreSQL 18 deprecates MD5 authentication and says support will be removed in a future major release, so reset those passwords while you are already in a maintenance window. Two more things. In link mode the old cluster is unsafe to start once the new one has run, as the pg_upgrade docs warn, so your rollback is the backup from step 3, not the old directory. And keep that old directory until the application has run a full business cycle on 18, then delete it with the delete_old_cluster.sh script pg_upgrade leaves behind. The same habit that keeps Postgres current applies to every base image you run. We covered it for PHP in PHP2Shell: patch the PHP underneath WordPress, and the planning side of a hard end-of-support date in our Exchange 2016/2019 exit plan. If you are cleaning up a compose stack anyway, sending container logs to stdout is another small fix worth doing in the same pass. Frequently asked questions Will my PostgreSQL 14 database stop working on 12 November 2026? No. It keeps running. End of life means the project stops releasing fixes, so security and data corruption bugs found after the final 14 release will not be patched. Can I upgrade from 14 straight to 18? Yes. pg_upgrade supports any source from 9.2 onward, and dump/restore works across any versions. Read the release notes of 15, 16, 17 and 18 for incompatibilities first. Should I wait for PostgreSQL 19? We would not. 19 is planned for 19 November 2026, after 14 loses support. Upgrading to 18 now and to 19 later is two planned jobs instead of one rushed one. Is it enough to change the image tag from 14 to 18? No. The data directory has to be upgraded with pg_upgrade or dump/restore. With an old-style mount, the 18 image refuses to start and points you to pg_upgrade. Sources: PostgreSQL versioning policy, PostgreSQL 19 RC 1 announcement, PostgreSQL 18 release notes, PostgreSQL 14 release notes, pg_upgrade documentation, Amazon RDS for PostgreSQL release calendar, postgres image documentation and tianon/docker-postgres-upgrade. Commands tested on Docker with postgres:14 (14.24) and postgres:18 (18.6) on 1 November 2026. Originally published on fanpino.com.

pushed an update to my H3 Relay Hires nodes fast fight scenes used to get re-staged when De-rope cleaned them up, camera would drift and poses changed. now it keeps your shot and the 1920 upscale step is about twice as fast with the same look tazmannner/ComfyUI-H3-RelayHires t.co

π0.5 now runs faster on less memory. 🤖 Inference dropped from 230 ms to 87 ms. 🤖 Rollout VRAM dropped from about 22 GB to 11.2 GB so it fits on a 16 GB card. The code is open: PrismaXAI/prism-pi

Subliminal Reinforcement Learning: traits travel through a judge's scores Keuntae Kim, Yong Suk Choi arxiv.org [𝚌𝚜.𝙰𝙸] 💬Code: kkt94/subliminal-rl t.co

Graphify-Labs/graphify

为把 Caps 改成 Ctrl，装了 200 多兆的厂商驱动，开机自启常驻，系统更新就失效。 keyd 后台服务：配置文件几行搞定换键/切层/宏，立即生效，占用可忽略，配置纯文本。 rvaiya/keyd

同时开 3 个 AI 对话干活，最忙的反而是你自己？ DeepSeek 开源了一个 Agent 原型，思路像包工头带工人：Router 跟你对话、派活，Worker 各领一份活同时开工。 它是给程序员的研究原型，不是正式产品。但方向很清楚：以后只跟一个 AI 说话，它替你管一群 AI。 deepseek-ai/dsh-superagent-prototype

BIG LOVE github.com/lynnswap/NeoSimulator/releases/tag/v0.…

GNUstep Desktop (GSDE) is modern Linux desktop environment that will give you NeXT/OpenStep- user experience. It runs on top of GNUstep framework and includes many wonderful apps and utilities that GNUstep community has developed. onflapp.github.io onflapp/gs-desktop t.co

Update from the bell on Home or Talkies settings → Updates. New to Talkies? Downloader code 5153858. Thanks to Swakshan for the StreamRadar tip, and to everyone who asked for NBA/NFL and a country picker 🙏 github.com/rajupp/talkies/releases/tag/v1.2.7

@honjo_yosage Here is my github github.com/gaziraihan1 Due to monitor issue I'm not active right now, but if you think I'm good fit then I'll manage a monitor and start working.

model: Anima Base-1.0 (by CircleStone Labs LLC) LoRA: 自作LoRA 2xLexicaRRDBNet by Philip Hofmann (Phhofm), licensed under CC BY 4.0 – github.com/Phhofm/models/%E2%80%A6

i ported/forked the new agent-desktop stuff that hit last friday to @AmpCode - was quite a bit more work than i thought but it works! Agentifiers/agent-desktop

The Clown Context Suite has changed its name to the Geiru Context Suite. Its a custom node suite specializing in long form MiniMax H3 vid gen and it helps reduce / eliminate vid gen degradation over long gens. roycho87/geiru_context_suite

12 agent skills that stop your AI from writing copy you’d be embarrassed to ship I built a set of skills for coding agents (Claude Code, Cursor, anything that reads AGENTS.md) around one rule: a hook has to survive the second look. If a reader later sees how the page or onboarding flow was built, they should respect the craft instead of feeling played. Here’s what each part does for you. Writing that doesn’t sound machine-made. The anti-slop skill has 85 rules covering the structural tells that survive after you ban the obvious words: uniform sentence weight, claim-example-moral paragraphs, “While X, Y” openers, abstract nouns as subjects. It also covers Vietnamese, Spanish, French, German and CJK boilerplate. The writing skill adds openers, a fix for the usual drop-off around paragraph three, a mid-article turn to keep people reading, and closers that end on something useful. Copy that converts without the usual tricks. The marketing skill bans fake scarcity and unbounded ROI claims, and asks you to tell one segment of readers not to buy. It gives a five-block landing page layout where you show pricing early and name your product’s ugly edge cases yourself. The trust skill covers six ways to earn belief before you ask for anything, such as admitting a flaw first or showing the work behind a result. Knowing who you’re writing for. One skill sets tone and proof type for four readers: a skeptical engineer, a time-poor buyer, a fast scroller, and a forum crowd. Another reads real 2 to 4 star reviews and competitor gaps, then drops any trend that has no causal link to your topic. Better ideas. The ideation skill throws out the first three obvious ideas, then forces a collision between a real user complaint and a structural lens. A compounding skill layers three or four mechanisms into one hook so you’re not stacking pressure tactics. Product flows. The product skill covers the first 60 seconds (value before signup), a day 1 to day 30 habit path, share links that work without login, and an offboarding flow that makes leaving as easy as joining. A visual skill handles layout, choice limits and response timing. A gate before you ship. value-check is 12 yes/no questions. Are the numbers real? Can a user cancel in as many clicks as it took to join? Would they feel manipulated reading your design notes? There’s also a scanner you can run without the agent: python3 tools/slop_scan.py draft.txt --fix-hints It scores text 0 to 100 and lists what to rewrite. Python 3.10+, no dependencies. Limits: the 15/100 cutoff is a heuristic, so it can flag human writing. Many of the psychology mechanisms replicate poorly, and the repo rates each one STRONG, MIXED or WEAK. I haven’t tested the plugin install from a clean machine. Install as a Claude Code plugin: /plugin marketplace add Vumb-VibeCoder/hook-everything /plugin install hook-everything@hook-everything MIT licensed. Repo: Vumb-VibeCoder/hook-everything

WHM Contact Provider - Ntfy This has been shared before on cPanel's discord. preview.redd.it Wanted to share with others who do want to expand on the capabilities and management of their hosting enviroment. github.com/rubix-studios-pty-ltd/whm-scripts/tree… Attach is the code to enable ntfy.sh as a contact provider, an opensource alternative to Pushbullet and similar service. Adding the contact provider requires only two scripts with explaination on how to use and install the script within the readme. The coding itself is a base to expand into other notification systems such as gotify. Along with this script, we've updated our Tauri/Rust application which previously was a thin web wrapper for ntfy with an automation and scheduling system. preview.redd.it rubix-studios-pty-ltd/ntfy-app With both components configured against a self-hosted ntfy.sh instance, you can receive WHM/cPanel server alerts directly on your desktop. Both projects are open source and actively maintained, feel free to provide suggestions, contributions and bug reports.