DEV CommunityThe Giantsread at source
Hybrid Humanity: Cognitive Architecture after AGI
The article analyzes the vision of Hybrid Humanity, where AI cognitive augmentations become tools for real agency. The author refers to the 'capability approach', indicating that technology should increase actual human capabilities rather than being a mere luxury for elites. A key threat is the emergence of new classes based on coupling quality—a divide between those with audited systems and those dependent on models optimized for corporate interests. The text advocates for the creation of a polycentric network of intelligent institutions (Supersociety) which, instead of monolithic management, emphasizes infrastructural pluralism and the independence of cognitive processes. Freedom in a post-AGI world thus depends on open standards and the ability to switch augmentation providers, making competition policy a foundation of cognitive freedom.
DEV CommunityThe Giantsread at source
Before you ship your side project, run three commands: Yatta JS's doctor, migrate, and backup
Side projects rarely die because the idea was bad. They die in the gap between "it works on my machine" and "it survives real users" — the database migration nobody ran, the backup nobody took, the misconfiguration nobody noticed until launch day. Yatta JS is a backend-as-a-server for Bun: database, auth, mail, storage, realtime, jobs, and observability embedded in your application process instead of provisioned as separate services. It is live as yatta.js@1.0.0 on npm — install it with npm i yatta.js — and the docs are at https://yatta.js.org . What I want to talk about today is not the architecture, though. It is the three boring commands that sit between a demo and a shipped thing. Doctor first: check the patient before the launch Every framework has a setup guide. Few of them will look at your actual project and tell you what is off. Yatta's doctor command does that job: it checks your project setup and flags problems before they become launch-day surprises. My rule now is simple: doctor runs before every deploy, not after something breaks. It is the cheapest form of confidence a solo builder can buy, and it costs nothing because the check is local to your own project. If you take one habit from this post, take this one — verify the setup, don't assume it. Migrations as a normal part of the workflow, not a scary event A side project that never changes its data model is a side project that never ships a second feature. Yatta's CLI treats migrations as ordinary work: make a migration, check migration status, run the migration. That rhythm matters more than any single command, because it turns schema changes from a dreaded manual step into a repeatable one you do without thinking twice. The practical payoff is unglamorous and real: your local database, your staging data, and your production data move forward in the same steps, in the same order. When you are the only person on the project, that repeatability is your whole ops team. Backup before you need it, not after you lose something Yatta's CLI includes database backup and restore commands, and the honest truth is that most solo projects never test a restore until the day they need one. Build the habit the other way round: take a backup before a risky migration, and know that restore is a command you have already practised, not a README you are reading in a panic. That is the whole pre-ship checklist, and it fits in a short paragraph: run doctor, keep migrations routine, back up before risky changes. None of it is exciting. All of it is what keeps a one-person project alive past week two. None of this replaces good judgement — a backup you never tested is a hope, not a plan, and a migration you never reviewed is still your responsibility. But having doctor, migrate, and backup as first-class commands in the same runtime that already holds your database, realtime, and jobs means the unglamorous work stops being a separate project. It is just part of shipping. If you are building on Bun and you are tired of assembling a backend from six services before you write a single feature, Yatta JS is worth a look: https://yatta.js.org — npm: https://www.npmjs.com/package/yatta.js — code: https://github.com/psrockstar098/yatta.js What is the one pre-launch check you always skip and always regret? I would genuinely like to steal better habits from the comments.
DEV CommunityThe Giantsread at source
MAJOR UPDATE!! FatafatOS 81 updated🔥
MAJOR UPDATE!!! FatafatOS 81 Updated 🔥 Yes, you heard it right. FatafatOS 81 just got a CRAZY update. NEW SPECS 🔥 CPU : Old i5 Processor and low graphics - yes, it runs on that old laptop you were about to throw away! RAM : Almost 1 or 0 MB sometimes - so lightweight you won't even feel it. BOOT TIME : 3 seconds - Blink and it's ON. FLOPPY : Floppy Available. Yes, FLOPPY is back. Why this update is different? Everyone is making OS heavier. I am making it lighter. Windows needs 8GB RAM. FatafatOS 81 needs almost 0. This is not an OS. This is FATAFAT. Built in Elikatta, Telangana, India. By - Karthik | Fatafat321 Developer Comment your PC specs, I will tell you if FatafatOS 81 will run on it.
DEV CommunityThe Giantsread at source
Spring Security API key authentication for REST APIs tutorial — Complete Guide
Spring Security API key authentication for REST APIs tutorial — Complete Guide A practical, in-depth guide to Spring Security API key authentication for REST APIs tutorial with examples. INTRO Every day we ship micro‑services that expose JSON endpoints to internal tools, mobile apps, or third‑party partners. The default Spring Security setup assumes a session‑based, form‑login flow—perfect for web UIs but a poor fit for stateless APIs. When you try to protect a REST endpoint with the out‑of‑the‑box configuration, you quickly hit a wall: CSRF tokens, redirects, and HttpSession objects start leaking into your API contract, forcing clients to handle cookies they never asked for. The pragmatic solution is to replace the heavyweight OAuth dance or JWT boilerplate with a simple API key. An API key is just a secret string that a client includes in each request, typically via a header. It’s easy to generate, rotate, and audit, and it works flawlessly with Spring’s filter chain. The challenge isn’t the concept—it’s wiring the key check into Spring Security without breaking the rest of your configuration, handling missing or malformed keys gracefully, and keeping the implementation testable. If you’ve ever written a custom OncePerRequestFilter that felt like a hack, or you’ve been forced to expose your endpoints without any protection because “security is too hard,” this guide will show you a clean, production‑ready way to integrate API key authentication directly into Spring Security’s authentication manager. WHAT YOU'LL LEARN How to define a lightweight AuthenticationToken that represents an API key and plug it into Spring’s AuthenticationProvider . Configuring the security filter chain to intercept requests, extract the key from a custom header, and delegate to the provider. Storing API keys securely using Spring Data JPA, with hashing and rotation strategies. Writing unit and integration tests for the filter, provider, and controller layers without starting a full server. Common pitfalls such as leaking keys in logs, handling multiple keys per client, and mixing API key auth with other mechanisms. Production hardening tips: rate limiting, revocation, and monitoring key usage with Spring Actuator. A SHORT CODE SNIPPET // 1. Simple Authentication token that holds the raw API key public class ApiKeyAuthenticationToken extends AbstractAuthenticationToken { private final String apiKey ; private final UserDetails principal ; public ApiKeyAuthenticationToken ( String apiKey ) { super ( null ); this . apiKey = apiKey ; this . principal = null ; setAuthenticated ( false ); } public ApiKeyAuthenticationToken ( UserDetails principal , String apiKey , Collection extends GrantedAuthority > authorities ) { super ( authorities ); this . apiKey = apiKey ; this . principal = principal ; setAuthenticated ( true ); } @Override public Object getCredentials () { return apiKey ; } @Override public Object getPrincipal () { return principal ; } } This token is the cornerstone of the authentication flow. The filter extracts the header, creates an unauthenticated instance, and hands it to the provider. If the key matches a stored record, the provider returns an authenticated token populated with the user’s authorities. KEY TAKEAWAYS Leverage Spring’s extensibility : By creating a custom AuthenticationToken and AuthenticationProvider , you keep the API key logic out of controllers and let Spring handle the heavy lifting. Never store raw keys : Hash the API key (e.g., BCrypt) before persisting, and compare hashes during authentication to mitigate leakage. Fail fast and stay silent : Return 401 Unauthorized without revealing whether the key was missing or invalid; this prevents enumeration attacks. Make it testable : Isolate the filter, provider, and repository so you can unit‑test each piece with mock requests and verify behavior under edge cases. 👉 Read the complete guide with step-by-step examples, common mistakes, and production tips: Spring Security API key authentication for REST APIs tutorial — Complete Guide
DEV CommunityThe Giantsread at source
Kimi K3.1 Pro โมเดล AI น้ำหนักเปิด 1 ล้านโทเคน เก่งจริงหรือแค่ชนะบนกระดาษ?
โดย Nokka (นก-กา) | ตรวจข้อมูล 24 ต.ค. 2026 บทความนี้เขียนโดย AI (deepseek-v4.1-flash · ผู้ให้บริการโมเดล: ollama-cloud) ผ่าน Hermes Agent ภายใต้การควบคุมและตรวจสอบคุณภาพโดยมนุษย์ - Nokka (นก-กา) Moonshot AI เปิดตัว Kimi K3.1 Pro เมื่อวันที่ 23 ตุลาคม 2026 [4] พร้อมคำกล่าวอ้างที่คุ้นหูว่าโมเดลนี้เข้าใกล้หรือเทียบชั้นโมเดลปิดชั้นนำ [1] ตัวเลขที่ถูกพูดถึงมากที่สุดคือ 65.7% บน Terminal-Bench 4.0 ซึ่งสูงกว่า GPT-6 Astra ที่ 58.2% และตามหลัง Claude Opus 5.5 ที่ 66.4% อยู่เล็กน้อย [1] ปัญหาคือตัวเลขชุดนี้มาจากตารางของบริษัทเอง และเมื่อผมไปเปิดกระดานของคนอื่น ตัวเลขกลับไม่เหมือนกัน บทความนี้จะแยกให้ดูว่าอะไรคือข้อเท็จจริงที่ตรวจได้ อะไรคือคำกล่าวอ้าง และอะไรคือกับดักเวลาอ่านข่าวแบบนี้ เกิดอะไรขึ้น Kimi K3.1 Pro เป็นโมเดลแรกในซีรีส์ K3.1 และเป็นโมเดลน้ำหนักเปิดที่บริษัทเรียกว่า "ระดับ 3T" ตัวท็อปที่สุดเท่าที่เคยทำมา พร้อมหน้าต่างบริบท 1 ล้านโทเคน [1] บริษัทระบุว่าเป็นเวอร์ชัน post-train ต่อจาก Kimi K3 โดยใช้กำลังคำนวณช่วง post-training มากขึ้นกว่ามาก [1] พร้อมกันนั้นมีอีกเวอร์ชันชื่อ Kimi K3.1 Pro Highspeed ที่บริษัทบอกว่าเร็วกว่า 2 ถึง 3 เท่า [1] ทั้งสองเวอร์ชันใช้ได้วันนี้บน Kimi.ai, Kimi Work, Kimi Code และ Kimi API ส่วนน้ำหนักโมเดลเต็มจะปล่อยภายในวันที่ 4 พฤศจิกายน 2026 [1] จุดสุดท้ายนี้สำคัญ เพราะแปลว่าวันนี้ยังไม่มีอะไรให้ดาวน์โหลดไปรันเอง ต้องรออีกราวสิบวัน สามตัวเลขที่คนพูดถึง ตัวเลขที่บริษัทรายงานเอง หนึ่ง Terminal-Bench 4.0 ที่ 65.7% เป็นชุดทดสอบที่วัดว่า agent ใช้ terminal แก้งานจริงได้แค่ไหน โดยมีเทสต์เฉพาะงานเป็นตัวตัดสิน [1] สองอัตราการ hallucination ลดจาก 23.4% เหลือ 8.3% บนชุดทดสอบภายในชื่อ Kimi Hallu Bench Hard [1] สาม Kimi Code Bench 3.0 แบบ long-horizon ได้ 61.2% เทียบกับ Kimi K3 ที่ 55.95% [1] ทั้งสามตัวเป็นการวัดของบริษัทเอง ยกเว้นตัวแรกที่มีกระดานภายนอกให้เทียบ แต่ตัวเลขเดียวกัน สองแหล่งไม่ตรงกัน ตรงนี้คือส่วนที่ผมคิดว่าผู้อ่านควรเห็นมากที่สุด บริษัทเขียนว่า Opus 5.5 ได้ 66.4% บน Terminal-Bench 4.0 และบอกด้วยว่า คะแนนของคู่แข่งนั้น "นำค่าสูงสุดที่รายงานไว้ในบล็อกหรือบนกระดานทางการ" มาใช้ [1][3] แปลว่าตารางเดียวกันอาจผสมผลจากการรันคนละแบบ คนละ harness คนละการตั้งค่า เมื่อผมเปิดหน้าผลของ Artificial Analysis ซึ่งเป็นคนละเจ้าของการวัด พบว่า Kimi K3.1 Pro ได้ 67.2% เป็นอันดับหนึ่ง ตามด้วย Claude Sonnet 5.5 ที่ 63.6% และ Opus 5.5 ที่ 59.6% [2] โดยหน้ารายละเอียดระบุว่าใช้ mini-swe-agent และโหมด Max, Default Fallback จะเห็นว่า Opus 5.5 ในสองแหล่งต่างกันถึงเกือบเจ็ดจุด ขณะที่อันดับของ Kimi กลับสูงขึ้น นี่ไม่ใช่การโกหกของใคร แต่เป็นธรรมชาติของ benchmark สมัยนี้ ที่คะแนนขึ้นกับ harness, reasoning effort, temperature และวิธีให้คะแนน [1] ถ้าจะสรุปให้สั้นที่สุด คือ ตัวเลข benchmark ใช้เปรียบเทียบได้เฉพาะเมื่อรันด้วยเงื่อนไขเดียวกัน และข่าวส่วนใหญ่ไม่ได้บอกเงื่อนไขนั้น อัตรา hallucination 8.3% อ่านอย่างไร ชุดทดสอบภายในไม่ใช่กระดานสาธารณะ ตัวเลขนี้ฟังดูน่าตื่นเต้น แต่ต้องอ่านคำกำกับให้ครบ บริษัทระบุชัดว่าเป็นชุดทดสอบ ภายใน ชื่อ Kimi Hallu Bench Hard ซึ่งออกแบบมาเพื่อกดดันความแม่นยำโดยเฉพาะ และคำถามถูกสร้างให้ยากเป็นพิเศษ [1] การวัดเป็นระดับข้อความย่อย ไม่ใช่ระดับคำตอบทั้งก้อน และผู้ตัดสินว่าเป็น hallucination คือ agent ที่ทำหน้าที่ตรวจข้อเท็จจริง [1] บริษัทเสริมว่า สัดส่วนคำตอบที่มีข้อผิดพลาดอย่างน้อยหนึ่งจุด เหลือเพียง 42.4% ของรุ่นก่อน [1] แต่มีจุดที่ผมอ่านแล้วหยุดคิด บล็อกเดียวกันแนบกราฟที่ให้คะแนนคู่แข่งบนชุดทดสอบเดียวกันด้วย [1] บนกราฟชุด "Hard with tools" ตัวเลขที่ต่ำกว่าคือดีกว่า Kimi K3.1 Pro อยู่ที่ 8.3% ขณะที่ GPT-6 Astra อยู่ที่ 5.5% ส่วน Opus 5.5 อยู่ที่ 15.0% แปลว่าบนชุดทดสอบนี้ คู่แข่งตัวหนึ่งทำได้ดีกว่า Kimi และคู่แข่งอีกตัวทำได้แย่กว่า ทั้งหมดนี้ทำให้ตัวเลข 8.3% บอกอะไรได้จริงเรื่องการพัฒนา จาก K3 มาเป็น K3.1 Pro แต่ไม่ควรถูกอ่านว่าเป็นอันดับหนึ่งของตลาด เพราะการรันคู่แข่งบนชุดนี้ก็ทำโดย Kimi เอง ไม่ใช่การวัดอิสระ นี่คือความต่างระหว่าง "ดีขึ้นกว่าเมื่อวาน" กับ "ดีกว่าคนอื่น" ซึ่งสองอย่างนี้ไม่จำเป็นต้องเกิดพร้อมกัน ที่โมเดลทำได้จริงตามที่บริษัทโชว์ ส่วนที่จับต้องได้มากกว่าตัวเลข คือความสามารถเชิงงาน งาน 3D บริษัทบอกว่าโมเดลทำงานกับ Unity, Unreal Engine และ Godot ได้ รวมถึงฉาก Three.js และงานฟรอนต์เอนด์ และบริษัทอ้างว่าผลงาน 3D สามารถดาวน์โหลดไปพิมพ์สามมิติได้ผ่านเครื่องมือ 3D Make ของ Kimi [1] งานเงิน อ้างว่าทำงานแบบ end-to-end ได้ ทั้ง screening การวิเคราะห์ความสามารถทำกำไร และได้ 64.4 บน OfficeQA Pro v2 งานอ่านเอกสารการเงินจริงข้ามฉบับ [1] Financial Modeling ดีขึ้น 7.2 จุดจาก K3 ในงานสร้างโมเดลการเงินและตรวจสอบสูตร [1] งานโค้ดระยะยาว มี Kimi Code Bench 3.0 long-horizon เป็นตัววัดการทำงานหลายขั้นตอนและการใช้เครื่องมือต่อเนื่อง [1] ผมยังไม่ได้ลองเอง จึงรายงานตามที่บริษัทอ้างและระบุที่มาไว้ชัดเจน 1 ล้านโทเคนหมายความว่าอะไรกับงานจริง ข้อสังเกตทั่วไปข้อแรกคือ บริบท 1 ล้านโทเคนมักถูกเข้าใจว่า "จำได้หมดทุกอย่าง" ซึ่งไม่จริง สิ่งที่บริบทใหญ่ช่วยคือการวางงานหลายชิ้นไว้ในบทสนทนาเดียว เช่น อ่าน repo ทั้งก้อน เอกสารหลายร้อยหน้า หรือ log ยาว ๆ โดยไม่ต้องตัดทิ้ง แต่คุณภาพการดึงข้อมูลจากบริบทนั้นเป็นคนละเรื่องกับขนาดบริบท และนี่คือจุดที่โมเดลต่างกันมาก บริษัทเองก็วางตำแหน่งโมเดลนี้ไว้ที่งาน agentic และงานยาว ซึ่งเป็นที่ที่บริบทใหญ่มีประโยชน์จริง ไม่ใช่งานถามตอบสั้น ๆ [1] ถ้าจะลอง เริ่มตรงไหน ผ่านเว็บ ใช้ Kimi.ai ได้ทันที ผ่านเครื่องมือเขียนโค้ด เปิด Kimi Code แล้วเลือกด้วยคำสั่ง /model ผ่าน API เลือกชื่อโมเดลตามนี้ และมี Zero Data Retention สำหรับลูกค้า API [1] kimi-k3.1-pro เวอร์ชันมาตรฐาน kimi-k3.1-pro-highspeed เร็วขึ้น 2-3 เท่า ตามที่บริษัทระบุ รอโหลดไปรันเอง ต้องรอถึง 4 พฤศจิกายน 2026 [1] สิ่งที่ควรระวัง คำว่า 3T-class เป็นการบอกระดับ ไม่ใช่จำนวนพารามิเตอร์ที่ยืนยันได้จากเอกสารสาธารณะ ตารางเปรียบเทียบของบริษัท รวมคะแนนจากหลายแหล่ง ซึ่งบริษัทเองก็ระบุไว้ในหมายเหตุ คำว่า open-weight วันนี้ยังเป็นคำสัญญา ไม่ใช่ไฟล์ที่ดาวน์โหลดได้ ความสามารถด้านไซเบอร์ บริษัทบอกว่าตั้งใจให้ต่ำกว่าขีดสุดของตัวเอง และยังตามหลังโมเดลปิดชั้นนำที่เปิดให้ใช้มาแล้วอย่างน้อยสามเดือน [1] เป็นการตัดสินใจเชิงนโยบาย ไม่ใช่ข้อจำกัดทางเทคนิค ใครควรลอง ใครยังไม่ต้อง ควรลองถ้า งานคุณต้องยัดเอกสารหรือโค้ดจำนวนมากเข้าไปในครั้งเดียว หรือกำลังมองหาโมเดลเปิดสำหรับงาน agent ที่ต้องรันเองในอนาคตอันใกล้ ยังไม่ต้องถ้า คุณต้องการรันในเครื่องตัวเองตั้งแต่วันนี้ เพราะยังไม่มีน้ำหนักให้โหลด หรือถ้างานคุณสั้นและตรงไปตรงมา จนบริบท 1 ล้านโทเคนไม่มีประโยชน์ และถ้าคุณกำลังจะอ้างตัวเลขจากข่าวนี้ในที่ประชุม ผมแนะนำให้พูดว่า "คะแนนบน Terminal-Bench 4.0 อยู่ราว 65 ถึง 67 เปอร์เซ็นต์ ขึ้นกับคนวัด" มากกว่าเลือกตัวเลขเดียวมาพูด ปิดท้าย ผมมองว่าข่าวนี้ไม่ได้น่าสนใจเพราะ Kimi ชนะหรือแพ้ Opus 5.5 แต่น่าสนใจเพราะช่องว่างระหว่างโมเดลเปิดกับโมเดลปิดแคบลงจนการวัดกลายเป็นเรื่องยาก เมื่อของสองฝั่งใกล้กันถึงระดับนั้น ตัวเลขหลักหน่วยจะบอกอะไรได้น้อยลงเรื่อย ๆ และคำถามที่ตอบยากขึ้นคือ งานของคุณต้องการอะไรจริง ๆ ซึ่งเป็นคำถามที่ไม่มี benchmark ไหนตอบแทนได้ REF [1] Kimi (Moonshot AI, 2026) · Kimi K3.1 Pro Tech Blog: Advancing Open Intelligence. https://www.kimi.ai/blog/kimi-k3-1-pro [2] Artificial Analysis (2026) · Terminal-Bench 4.0 leaderboard. https://artificialanalysis.ai/evaluations/terminalbench-4-0 [3] Terminal-Bench (2026) · กระดานและระเบียบวิธีทดสอบ. https://www.tbench.ai/ [4] Kimi Forum (2026) · Kimi K3.1 Pro has launched. https://forum.moonshot.ai/t/kimi-k3-1-pro-has-launched-start-exploring-now/629