# C Published articles for C. This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## Real-Time Java: Control Loops the Garbage Collector Never Stops DevFeed: [Real-Time Java: Control Loops the Garbage Collector Never Stops]() Original publisher: [Read original article]() Author: Shai Almog Published: 2026-11-09T00:00:00Z Content type: article Language: en Sources: [CodeName One]() Topics: [real-time](), [scheduling]() Tags: [api](), [array](), [atomic](), [audio](), [boolean](), [boxing](), [build](), [c](), [capabilities](), [certification](), [ci](), [codename](), [collector](), [control](), [control-loops](), [garbage-collection](), [java](), [loops](), [real-time](), [time]() ### AI overview The post describes Codename One's firm real-time Java control loops on PREEMPT_RT Linux. Its ahead-of-time ParparVM code avoids JIT variability, while the collector keeps real-time thread references visible through a write barrier and does not run stop-the-world phases while those threads execute. Build-time checks reject allocations reachable from cycle(); runtime checks catch some calls the translator cannot resolve. Priority-inheriting mutexes, locked memory, and CPU pinning address other delays. The example schedules a 1 kHz motor loop on an absolute clock and reports missed periods instead of catching up in a burst. The approach is not certified hard real time: kernel and hardware determine latency, so the author advises measuring on the target board and checking that scheduling was applied. The text gives no latency figures. ### Source excerpt What real time means, why garbage collection makes it hard, and how Codename One runs a 1 kHz Java control loop that the collector never stops. ## parse\_number() as a SQLite extension: C vs Rust DevFeed: [parse\_number() as a SQLite extension: C vs Rust]() Original publisher: [Read original article]() Author: Simon Willison Published: 2026-11-08T22:26:00Z Content type: article Language: en Sources: [Simon Willison's Weblog]() Topics: [SQLite](), [Rust](), [AI Chat]() Tags: [c](), [c-55](), [claude](), [claude-325](), [function](), [parsing](), [performance](), [research](), [research-12](), [rust](), [rust-116](), [sqlite](), [sqlite-490]() ### AI overview The reported C SQLite extension was much smaller than the Rust versions (14 KB versus 321 KB with Rusqlite and 298 KB with sqlite-loadable-rs), but initially slower. Replacing C's strtod-based parsing with a custom parser using "Clinger's fast path" improved its reported net cost per row over two million rows: 19 ns on mixed data, 16 ns on integers, and 18 ns on decimals, compared with 46/36/55 ns for Rusqlite and 41/32/47 ns for sqlite-loadable-rs. The supplied excerpt describes the experiment and results but does not include implementation details or the full report. ### Source excerpt Research: parse_number() as a SQLite extension: C vs Rust I was out walking the dog when I got curious about how easy/difficult it would be to write a SQLite C extension that adds a parse_number() function for turning strings like -$1,234.56 or '12.5%' into numeric values that could be summed and sorted. I fired up regular Claude chat (Opus 5.5) and prompted: I'm thinking about a SQLite custom function 'parse_number(value)' that strips ',', '$', 'GBP ' and '%', handles a leading '-', and returns 'NULL' for anything it can't parse Explore the difference between building this as a SQLite extension in C v.s. in Rust - I want to compare performance and code complexity and size of the resulting.so(or whatever) file This gave me a solid starting point - the Rust extension was 321 KB (using Rusqlite) and 298 KB (using sqlite-loadable-rs), while the C extension was 14 KB. But the Rust extension was faster! Turns out that's because the Rust equivalent of C's strtod is "twice as fast". So I prompted: Try writing your own C function for parsing text into a decimal number that catches up to or beats the Rust implementation And it did, using "Clinger's fast path": Net cost per row over 2 million rows, lower is better: first C new C rusqlite sqlite-loadable Mixed data 67 ns 19 ns 46 ns 41 ns Integers only 25 ns 16 ns 36 ns 32 ns Decimals only 106 ns 18 ns 55 ns 47 ns Finally, I had it rewrite the prototype as a research report to match the others in simonw/research by prompting this: Clone simonw/research from GitHub and turn your above investigation into a research report as seen in that repository - you can give me a zip file to download that contains your new folder Here's the resulting report. Tags: c, research, sqlite, rust, claude ## MoofTCP is a modern replacement for MacTCP on 68k Macs DevFeed: [MoofTCP is a modern replacement for MacTCP on 68k Macs]() Original publisher: [Read original article]() Author: Anne Barela Published: 2026-11-06T20:49:33Z Content type: news Language: en Sources: [Adafruit Industries]() Topics: [DHCP](), [GitHub]() Tags: [68k-mac](), [adapter](), [apple](), [bug](), [c](), [client](), [control-panel](), [dhcp](), [drop-in](), [github](), [history](), [installer](), [linux](), [mactcp](), [modern](), [networking](), [portable](), [replacement](), [software](), [stack](), [system](), [tcp](), [tcp-ip](), [vintage-computing]() ### AI overview MoofTCP is a drop-in MacTCP replacement for 68k Macs running System 6: existing MacTCP programs run unchanged, while a new TCP/IP stack written in portable C handles networking. Built for a 4 MB Mac Classic, it uses no more resident memory than MacTCP and includes a control panel, installer, and DHCP client. The text reports testing on a Mac Classic with System 6.0.8 and a BlueSCSI v2 WiFi adapter using DaynaPORT, as well as in the Snow emulator. Returning to MacTCP requires running the installer and choosing Remove. MoofDiag can write MoofTCP's in-memory diagnostic log for bug reports; the code is MIT licensed and builds with a pinned Retro68 Docker image. ### Source excerpt Matt Richter has published MoofTCP on GitHub, a drop-in replacement for Apple's MacTCP networking software on 68k Macs running System 6. Programs written for MacTCP run on it unchanged, but underneath it's a fresh TCP/IP stack written from scratch in portable C, with its own control panel, installer and DHCP client. It was built for [...] ## The intensional model in disguise DevFeed: [The intensional model in disguise]() Original publisher: [Read original article]() Published: 2026-11-06T18:00:00Z Content type: article Language: en Sources: [Farid Zakaria's Blog]() Topics: [CI/CD]() Tags: [actions](), [bazel](), [behavior](), [binaries](), [build](), [building](), [builds](), [c](), [ca](), [cache](), [cat](), [cc](), [change](), [changes](), [clang](), [command](), [model](), [nix](), [prototype](), [store]() ### AI overview The article argues that Nix content-addressed derivations and Bazel/buck2 action caching implement the same intensional build model: outputs are identified by content, and actions key off command lines and input content digests. In its C example, changing a comment makes the compile action run, but leaves the object file unchanged, so Bazel and buck2 reuse the link action's cached result. Nix defaults to an extensional model, where recipe and upstream input changes propagate through store paths and trigger downstream rebuilds; enabling content-addressed derivations lets it avoid rebuilding the unchanged link output. Bazel and buck2 use the intensional model by default and offer no input-addressed mode, while Nix supports both. The excerpt identifies early cutoff as the resulting optimization and says its granularity helps explain why people use Bazel and buck2 for large builds until Nix dynamic derivations stabilize. ### Source excerpt Despite how different they look on the surface, Nix, Bazel and buck2 are remarkably similar under the hood. Don't believe me? I built a prototype in one store, two frontends to prove it. Turns out though that the similarities are even deeper than I realized. ## Hackers Target OpenSSH SSHole Flaw Within Hours of Disclosure, Gain Root on Honeypot DevFeed: [Hackers Target OpenSSH SSHole Flaw Within Hours of Disclosure, Gain Root on Honeypot]() Original publisher: [Read original article]() Author: The Hacker News Published: 2026-11-06T15:21:49Z Content type: news Language: en Sources: [Cyber Newsroom]() Topics: [Vulnerabilities](), [known exploitable vulnerabilities](), [cve remediation]() Tags: [account](), [alpine](), [alpine-linux](), [asterisk](), [attack](), [authentication](), [bypass](), [c](), [commands](), [configuration](), [cve-2026-123158](), [cyber-attack](), [exploit](), [honeypot](), [linux](), [network-security](), [openssh](), [password](), [previdian](), [root](), [security](), [sshole](), [vulnerability]() ### AI overview SSHole (CVE-2026-123158) can let an unauthenticated attacker log in with an oversized password to an account whose password field contains an asterisk, when OpenSSH runs on musl-based Linux with PAM disabled. A failed password-hashing operation can return the same asterisk used for password-disabled accounts, which sshd then accepts; accounts with valid password hashes are not affected. The flaw was fixed in OpenSSH 10.6p2. Previdian reported attempted exploitation within nine hours of disclosure and confirmed root access on an Alpine Linux honeypot. The excerpt says the flaw does not affect Dropbear, glibc-based distributions, non-Linux systems, or systems using PAM password checks. Affected users should install the fixed or distribution-patched package and restart sshd; Alpine recommends reviewing suspicious "Accepted password for" log entries and related account activity. ### Source excerpt Hackers Target OpenSSH SSHole Flaw Within Hours of Disclosure, Gain Root on Honeypot Threat actors are attempting to exploit a recently disclosed security flaw impacting OpenSSH that can enable sign-ins to accounts that have no password set, according to Previdian. The vulnerability, ... Read more Published Date: Nov 06, 2026 (7 hours, 17 minutes ago) Vulnerabilities has been mentioned in this article. CVE-2026-123158 CVE-2016-6210 ## Large Language Models for Multi-Lingual Equivalent Mutant Detection: An Extended Empirical Study DevFeed: [Large Language Models for Multi-Lingual Equivalent Mutant Detection: An Extended Empirical Study]() Original publisher: [Read original article]() Author: Honglin Shu, Zhao Tian, Dong Wang, Junji Yu, Jiazhe Zhang, Xuejie Cao, Junjie Chen, Yasutaka Kamei Published: 2026-11-06T05:00:00Z Content type: article Language: en Sources: [arXiv: Software Engineering]() Topics: [Large Language Model](), [LLM evaluation / benchmarking]() Tags: [benchmark](), [c](), [code-analysis](), [compiler](), [cs-se](), [detection](), [effectiveness](), [efficiency](), [embedding](), [inference](), [java](), [language-models](), [large-language-models](), [large-language-models-llms](), [llm](), [llms](), [machine-learning](), [mutation-testing](), [programming-languages](), [semantics](), [training-data]() ### AI overview The study evaluates LLMs for equivalent mutant detection using 3,302 Java and 1,088 C mutant pairs. LLM approaches achieved higher F1-scores than the evaluated traditional methods; among tested strategies, fine-tuned code embeddings had the highest detection accuracy. Their inference times were comparable to existing machine-learning models, and fine-tuned LLMs showed measurable cross-language generalization. The abstract reports these results but gives no specific score values or detailed strategy comparisons. ### Source excerpt arXiv:2607.00511v2 Announce Type: replace Abstract: Mutation testing is a powerful technique for ensuring software quality. However, the presence of equivalent mutants introduces unnecessary costs and biases, limiting its practical effectiveness. Although numerous equivalent mutant detection (EMD) methods have been proposed, they often face distinct challenges: pure-code analysis methods can be limited by their reliance on specific compiler infrastructures, while existing machine-learning approaches remain constrained by scarce training data and limited generalization to unseen mutants. Large language models (LLMs) have recently demonstrated remarkable performance across diverse code-related tasks by better capturing program semantics. Yet their potential for EMD remains largely unexplored, particularly in the multi-lingual context. This paper presents the first comprehensive empirical study on LLMs for EMD, using 3,302 Java and 1,088 C mutant pairs to benchmark against state-of-the-art methods, explore strategy variations, assess efficiency, and evaluate cross-lingual generalization. Experimental results show that LLM-based approaches achieve higher F1-scores than the evaluated traditional methods, with fine-tuned code embedding yielding the highest detection accuracy among the tested strategies. Moreover, LLM-based approaches strike a practical balance between effectiveness and efficiency with inference times comparable to existing machine-learning models. Importantly, fine-tuned LLMs demonstrate measurable generalization across programming languages. These findings establish LLMs as a viable and efficient approach for tackling the longstanding challenge of equivalent mutant detection, offering new directions for advancing mutation testing in practice. ## Secure Formal Raising: Protecting the Development of AI through Executable Properties DevFeed: [Secure Formal Raising: Protecting the Development of AI through Executable Properties]() Original publisher: [Read original article]() Author: Rolf Drechsler, Christina Plump Published: 2026-11-06T05:00:00Z Content type: article Language: en Sources: [arXiv: Artificial Intelligence]() Topics: [ai security](), [Formal verification](), [Security]() Tags: [admission](), [ai](), [authorization](), [bounded](), [c](), [cs-ai](), [data](), [development](), [environment](), [exhaustive](), [exploration](), [flow](), [formal](), [gap](), [implementation](), [integrity](), [invariants](), [machine-intelligence](), [model](), [policy](), [properties]() ### AI overview Secure Formal Raising (SFR) extends Formal Raising by modeling policy integrity, authorization, and confidential data flow with four-valued evidence that retains unknown and inconsistent assessments. The paper proves six security invariants that require admission to rely only on confirmed evidence. A plain-C reference implementation meets those invariants in a bounded exhaustive exploration; the exploration also identifies a confused-deputy gap in tool calls, addressed by requiring provenance. ### Source excerpt arXiv:2611.08042v1 Announce Type: new Abstract: Model raising revisits Turing's developmental view of machine intelligence. Formal Raising (FR) has recently been proposed to complement this view with explicit behavioral properties. This paper extends that proposal to the security of the raising environment. Secure Formal Raising (SFR) models policy integrity, authorization, and confidential data flow using four-valued evidence that preserves unknown and inconsistent assessments. We prove six security invariants and show that they force admission to accept only confirmed evidence. A plain-C reference implementation satisfies the invariants in a bounded exhaustive exploration, which also exposes a confused-deputy gap for tool calls that a provenance requirement closes. ## ActQuant: Sub-4-bit Action-Guided Backbone Weight-Only Quantization for Vision-Language-Action Models DevFeed: [ActQuant: Sub-4-bit Action-Guided Backbone Weight-Only Quantization for Vision-Language-Action Models]() Original publisher: [Read original article]() Author: Arash Akbari, Arman Akbari, Masih Eskandar, Qitao Tan, Yixiao Chen, Jingwu Luo, Bertha Pangaribuan, Liyun Zhang, Jennifer Dy, Geng Yuan, Xue Lin, Gaowen Liu, Stratis Ioannidis, Yanzhi Wang Published: 2026-11-06T05:00:00Z Content type: article Language: en Sources: [arXiv: Artificial Intelligence]() Topics: [quantization](), [Post-training optimization]() Tags: [6-dof](), [actions](), [agent](), [agentic](), [architectures](), [arm](), [benchmark](), [bits](), [block](), [c](), [c-c-plus-plus](), [c-plus-plus](), [compute](), [cs-ai](), [cs-cv](), [language](), [models](), [quantization](), [vision](), [vision-language-action](), [vision-language-action-models](), [weight]() ### AI overview ActQuant reduces VLA backbone weight size through action-guided mixed-precision post-training quantization. It assigns each weight matrix a bit-width based on its contribution to action prediction, then tunes block-level scales using action-aware curvature. The accompanying OmniModel.cpp pipeline converts models to a native C/C++ runtime with low-bit kernels. On LIBERO, the abstract reports that ActQuant is the only evaluated method at or below 3 bits per weight, retaining 95.0% on OpenVLA-OFT and 94.8% on π₀.₅. At 2.5 bits per weight, OpenVLA-OFT retains 90.1% while its backbone shrinks from 14.3 GB to 2.7 GB. On a physical 6-DoF UR3 arm, quantized π₀.₅ retains baseline success rate with 2.5x lower memory use. The supplied material is an abstract and does not provide further experimental details. ### Source excerpt arXiv:2605.24011v4 Announce Type: replace-cross Abstract: Vision-Language-Action (VLA) models exhibit remarkable action generation for embodied intelligence, but their heavy compute make deployment on edge platforms impractical. Aggressive, sub-4-bit weight quantization is the natural solution, yet existing post-training quantization (PTQ) methods suffer severe performance degradation in this regime. To address this, we introduce ActQuant, an action-guided mixed-precision PTQ framework that operates in two stages: (1) an inter-tensor bit allocator that assigns each weight matrix a single bit-width based on how much it contributes to predicting the agent's actions; (2) an intra-tensor scale optimizer tunes per-block quantization scales using action-aware curvature, so that dynamic range is concentrated on the weights most influential for control. To deliver the on-device benefits of our aggressive quantization, we further introduce OmniModel.cpp, an agentic conversion pipeline that ports architectures into a native C/C++ runtime with efficient low-bit kernels. We evaluate ActQuant both in simulation and on a real-world 6-DoF UR3 arm, with all models deployed through OmniModel.cpp. On the LIBERO benchmark, ActQuant is the only method that operates at or below 3 bits-per-weight, retaining 95.0% on OpenVLA-OFT and 94.8% on $\pi_{0.5}$. Pushed further, ActQuant reaches 2.5 bpw at 90.1% on OpenVLA-OFT, compressing the backbone from 14.3 GB to 2.7 GB (5.3$\times$). On the physical UR3 arm, $\pi_{0.5}$ quantized with ActQuant retains the baseline's success rate while reducing the memory footprint by 2.5$\times$. ## Libghostty 1.0 DevFeed: [Libghostty 1.0]() Original publisher: [Read original article]() Published: 2026-11-06T00:00:00Z Content type: release Language: en Sources: [Mitchell Hashimoto]() Topics: [Terminal](), [Text-based user interface]() Tags: [abi](), [agentic](), [agentic-coding](), [ai](), [api](), [bare-metal](), [bash](), [bugs](), [build](), [c](), [c-plus-plus](), [emulation](), [ghostty](), [high-performance](), [library](), [net](), [release](), [stable](), [terminal](), [zig]() ### AI overview libghostty-vt 1.0 is a portable C terminal-emulation library extracted from Ghostty, with a stable ABI and semantic-versioning promises. Its API uses opaque handles, extensible getters and setters, and compatibility checks; CI checks ABI changes, and ELF builds version exported symbols. Releases include signed source and dependency tarballs for offline builds, standard packaging files, and platform-specific artifacts. The library is MIT licensed, has no runtime dependency beyond libc in its default configuration, and can be built freestanding with SIMD disabled. CI tests multiple operating systems and architectures; WebAssembly builds can omit selected features. It creates no threads, supports a customizable allocator, and the author reports running 10,000 active terminals on a four-core, 8 GB Linux server. The text lists adoption across IDEs, terminal tools, and other products, while noting overall usage estimates are rough. ### Source excerpt # Libghostty 1.0 `libghostty-vt` 1.0 is here. libghostty is a portable, high-performance C library for terminal emulation, extracted directly from the core of Ghostty. The 1.0 release means both the library itself and the C ABI are now stable. A little over a year ago, I wrote that libghostty is coming. At the time, the Zig module had just been merged, the C API didn't exist, and nobody but Ghostty was a consumer. ## A Tiny OS for a Tiny Board DevFeed: [A Tiny OS for a Tiny Board]() Original publisher: [Read original article]() Author: Jenny List Published: 2026-11-05T19:30:34Z Content type: article Language: en Sources: [Hackaday]() Topics: [RIOT](), [Jule]() Tags: [apps](), [aprs](), [c](), [compile](), [editor](), [esp32](), [esp32-s3](), [files](), [gps](), [headless](), [heltec](), [operating-system](), [operating-systems](), [os](), [sdk](), [serial](), [shell](), [software-hacks](), [terminal](), [tiny](), [unix](), [usb](), [weather]() ### AI overview KoaOS is a headless, UNIX-like operating system for the ESP32-S3 in the Heltec WiFi LoRa 32 V4, accessed through a serial terminal over USB. It includes an editor, GPS, weather, and APRS apps, and offers a C-based SDK for creating apps packaged as .esp files that can be installed or removed over the network. Its large PSRAM requirement currently limits it to the Heltec V4; support for similar boards is only speculative in the source. ### Source excerpt As microntrollers have become ever more powerful, we have started to see an increasing number of operating systems written to take advantage of this extra power. Usually they're aimed at ...read more ## OpenSSH Issues Emergency Fix for Flaw Letting Long Passwords Bypass SSH Auth on Alpine Linux DevFeed: [OpenSSH Issues Emergency Fix for Flaw Letting Long Passwords Bypass SSH Auth on Alpine Linux]() Original publisher: [Read original article]() Author: The Hacker News Published: 2026-11-05T16:42:46Z Content type: news Language: en Sources: [Cyber Newsroom]() Topics: [OpenSSH](), [ssh](), [Linux](), [credential-based attacks](), [passwd]() Tags: [ai](), [ai-agents](), [alpine](), [alpine-linux](), [apk](), [authentication](), [buildroot](), [c](), [cloud-init](), [containers](), [cve](), [denial-of-service](), [end-of-support](), [linux](), [network-security](), [open-source-security](), [openssh](), [passwords](), [ssh](), [vulnerability]() ### AI overview The flaw affects certain Alpine Linux SSH servers built without PAM when password logins are enabled, an account has no password, and another account has a `$5$` or `$6$` password hash. A network attacker who knows the passwordless account's name can log in by submitting a 257-1,024-byte password: musl's `crypt()` returns `*` for inputs over 256 bytes, which matches the passwordless account's stored `*`. OpenSSH 10.6p2 and fixed Alpine packages prevent the match; Alpine administrators should upgrade and restart `sshd`. Until then, disable `PasswordAuthentication` after confirming key access. Systems using PAM, glibc, or non-Linux platforms are not affected, according to the article. No attacks had been reported. ### Source excerpt OpenSSH Issues Emergency Fix for Flaw Letting Long Passwords Bypass SSH Auth on Alpine Linux Attackers can log in to accounts that have no password, such as SSH key-only accounts, on some Alpine Linux servers running the standard openssh-server package. They need network access to the server, ... Read more Published Date: Nov 05, 2026 (6 hours, 8 minutes ago) Vulnerabilities has been mentioned in this article. CVE-2016-6210 ## A performance trap: when store forwarding fails DevFeed: [A performance trap: when store forwarding fails]() Original publisher: [Read original article]() Author: Daniel Lemire Published: 2026-11-05T13:06:20Z Content type: article Language: en Sources: [Daniel Lemire]() Topics: [Intel Core](), [Algorithms]() Tags: [buffer](), [c](), [cache](), [compiler](), [cycles](), [epyc](), [example](), [experiments](), [failure](), [graviton](), [load](), [overlap](), [performance](), [processor](), [reading](), [reload](), [size](), [store](), [update](), [write]() ### AI overview Store forwarding lets a later load obtain bytes from a store buffer before the store reaches cache, but forwarding fails when the load is wider than the store or the accessed ranges only partly overlap; the load then waits for the store to reach cache. The excerpt's C example overwrites one byte and reloads eight, and notes the same issue for a 4-byte store followed by an 8-byte load or an 8-byte load shifted four bytes from an 8-byte store. It shows avoiding the mismatch by loading eight bytes into a register, modifying the byte there, then storing all eight back. In the reported experiments, matching store/load operations took one cycle on Xeons and EPYC; wider loads took 19 cycles on Xeons, 14 on EPYC, and 5 on M4 and Graviton 5. Two stores took 8 cycles on M4. A compiler may remove a reload when the same eight bytes are stored and read back. ### Source excerpt A store does not go straight into the cache. Waiting for that write would stall the processor. It sits in a store buffer, and a later load can take its bytes from that buffer. That is store forwarding. Forwarding works when the load is the same size as the store, or smaller and completely inside ... Continue reading A performance trap: when store forwarding fails ## Ocient raises $100 million as agentic AI drives growth in large-scale analytics DevFeed: [Ocient raises $100 million as agentic AI drives growth in large-scale analytics]() Original publisher: [Read original article]() Author: Paul Gillin Published: 2026-11-05T12:00:23Z Content type: news Language: en Sources: [SiliconANGLE]() Topics: [Agentic AI](), [Big data infrastructure](), [Artificial Intelligence]() Tags: [agentic](), [agentic-ai](), [agentic-artificial-intelligence](), [ai](), [ai-agents](), [analytics](), [analyze](), [artificial-intelligence](), [big-data](), [business](), [c](), [data](), [data-analyltics](), [data-analytics](), [data-warehouse](), [datasets](), [demand](), [funding](), [growth](), [large](), [national-security](), [news](), [ocient-inc](), [ocientaiq-solutions](), [ocientaiq-unified-data-platform](), [platform](), [raises](), [scale](), [the-latest](), [top-story-5](), [top-story-6]() ### AI overview Ocient raised $100 million in Series C funding to expand its OcientAIQ analytics business, bringing total funding to $260 million. Its platform lets AI agents and analysts query petabyte-scale datasets without sampling, combining data ingestion, analytics, governance and agent orchestration while minimizing data movement and using forward error correction instead of conventional replication to reduce storage overhead. The company reports growing demand from national security and telecommunications customers, including for cybersecurity analysis of complete historical network data; it provides infrastructure, not threat detection algorithms. Ocient says it often complements platforms such as Snowflake and Databricks, and that many current opportunities are on premises for cost, sovereignty or data protection reasons. It plans to use the funding for sales and customer delivery hiring, engineering, and geographic expansion; its CEO said the funding should help reach breakeven but gave no timetable. ### Source excerpt Ocient Inc., the maker of a speedy data analytics platform, today said it has raised $100 million in a Series C funding to expand its agentic artificial intelligence analytics business. That business is fueled by growing demand from national security organizations and telecommunications providers seeking to analyze massive datasets without sampling. The new round brings [...] The post Ocient raises $100 million as agentic AI drives growth in large-scale analytics appeared first on SiliconANGLE. ## CLion 2026.3 Is Here DevFeed: [CLion 2026.3 Is Here]() Original publisher: [Read original article]() Author: Oleg Zinovyev Published: 2026-11-05T11:27:05Z Content type: release Language: en Sources: [JetBrains]() Topics: [CLion](), [CUDA Tile](), [CMake](), [Tool](), [junie](), [Claude Code](), [GitHub Copilot](), [jetbrains-toolbox]() Tags: [2026](), [2026-3](), [agent](), [agentic](), [agentic-ai](), [agentic-development](), [agents](), [ai](), [air](), [c](), [c-plus-plus](), [clion](), [cmake](), [cuda](), [cuda-tile](), [dap](), [debugging](), [download](), [embedded](), [ispc](), [jetbrains](), [jetbrains-air](), [news](), [releases](), [trace32]() ### AI overview CLion 2026.3 adds JetBrains Air for running and reviewing agents, plus agent-assisted workflows for debugging ARM Cortex-M hard faults and diagnosing failed CMake loads. Air supports multiple agents and existing provider subscriptions, API keys, and custom base URLs; free Junie Lite is included with a JetBrains Account. Embedded debugging adds RTOS tasks, queues, and timers to agent tools. Debug profiles can be edited as JSON, with a dedicated TRACE32 launch and attach profile and configurable DAP working directories and environment variables. Language support includes CUDA Tile C++ for C++20 projects using CUDA Toolkit 13.3 or later, ISPC code insight, and automatic compiler headers and macros when no build targets provide settings. The release also adds class memory layout visualization and copies local project settings into Git worktrees. The Classic engine plugin's 2026.3 version is its last stable release; updates end in November 2026. ### Source excerpt With JetBrains Air, agent-assisted embedded debugging and CMake project setup, plus support for NVIDIA CUDA Tile C++ and ISPC. CLion 2026.3 is now available. This latest version of the JetBrains IDE for C and C++ includes the following key features: You can download CLion 2026.3 from the link below, via the Toolbox App, as a [...] ## Systemd Wants Rust in, But its Core Will Have to Wait DevFeed: [Systemd Wants Rust in, But its Core Will Have to Wait]() Original publisher: [Read original article]() Author: Sourav Rudra Published: 2026-11-05T10:12:32Z Content type: news Language: en Sources: [It's FOSS]() Topics: [Rust]() Tags: [abi](), [box](), [c](), [certificates](), [core](), [coreutils](), [filesystem](), [init](), [kernel](), [libc](), [library](), [linux](), [linux-kernel](), [memory-safe](), [news](), [rust](), [systemd]() ### AI overview systemd has merged optional support for new standalone Rust programs, with `systemd-keyring-setup` the first example; existing C code is not being ported. Rust programs must build through Meson without Cargo, may use only the `core` and `libc` crates, and must match their C counterparts' behavior. They require rustc 1.85, bindgen 0.71.1, and Meson 1.4.0 or newer, so distributions enabling every feature need the Rust toolchain or must disable Rust support. `libsystemd-shared` remains in C because Rust lacks a stable ABI and putting Rust there could duplicate code. Sensitive filesystem access is another obstacle: systemd relies on file-descriptor-based path lookup, which the excerpt says Rust's standard path handling does not provide. ### Source excerpt The rustification is ongoing, with Rust-written programs now allowed and existing C code not being ported. ## Porting a "Crappy" Flash Game to the IBM 5150 and Beyond DevFeed: [Porting a "Crappy" Flash Game to the IBM 5150 and Beyond]() Original publisher: [Read original article]() Author: Tyler August Published: 2026-11-05T09:00:11Z Content type: article Language: en Sources: [Hackaday]() Topics: [Game Development](), [ibm](), [browser-game]() Tags: [5150](), [adobe](), [assembler](), [browser](), [browser-games](), [bugs](), [c](), [c-plus-plus](), [cga](), [chip](), [coding](), [controller](), [cpc](), [crt](), [display](), [dos-3-3](), [flash](), [game](), [ibm](), [ibm-5150](), [pc](), [porting](), [retrocomputing](), [software-development]() ### AI overview The port displays a Flash game on an IBM 5150 by exploiting the CGA card's MC6845 controller: carefully timed assembler changes character height on the fly, creating a roughly 160 x 86 pixel window in text mode. The project uses Open Watcom V2 and implements the game in C as a large state machine, with testing across a range of DOS machines to find bugs. The excerpt identifies the display hack as the build's most impressive part; it does not provide further technical detail about the game port. ### Source excerpt Flash is obsolete and the IBM 5150 is obsolete. Therefore, by the transitive property of algebra, you should be able to run flash games on IBM's original PC, right? Okay, ...read more ## We can do better than line-buffered output DevFeed: [We can do better than line-buffered output]() Original publisher: [Read original article]() Published: 2026-11-05T00:25:25Z Content type: article Language: en Sources: [Chris Wellons]() Topics: [IO](), [Command-line interface](), [Terminal]() Tags: [2](), [applications](), [archive](), [automatically](), [avoid](), [better](), [buffer](), [but](), [c](), [can](), [comes](), [consider](), [cpython](), [doesn-t](), [don-t](), [event](), [example](), [experience](), [faster](), [file]() ### AI overview Terminal line buffering can slow noninteractive programs by flushing on each newline. In the author's `tugz` unzip, output stays visible without that per-line cost: the buffer is checked during short stints of work and flushed only after it has been idle for a brief deadline (suggested around 100 ms), allowing several filenames to be written together. This avoids extra writes without a thread and leaves the user interface unchanged. The excerpt contrasts this with glibc's newline-by-newline writes and CPython's flush when buffered output contains a newline, which can emit partial lines. ### Source excerpt Buffered output typically comes in two flavors: fully buffered and line buffered. If output goes to a terminal then the implementation automatically selects line buffering, flushing its buffer when a line is completed so that it reaches the user immediately. Otherwise it fully buffers, holding output until the buffer is full or an explicit flush event at some arbitrary point in the future. Line buffering is a common bottleneck in non-interactive terminal applications such that it's worth redirecting output to a file or pipe in order to avoid it. It doesn't have to be this way. We can have our cake and eat it, too: promptly delivering lines to a terminal at fully-buffered speeds. For example, Info-ZIP unzip prints file names as it extract them from an archive. This printout dominates extraction time of archives with many small files. Sometimes I run unzip without options, then my terminal floods with file names and I know that my extraction is bottlenecked. So I cancel and restart with -q (quiet) to avoid the bottleneck, because it's faster to start over than wait. Conscious of this experience, I avoided the problem in tugz unzip without changing the user interface. You get a listing but you don't have to pay for it. $ unzip example.zip Archive: example.zip inflating: example.bmp inflating: example.svg inflating: example.txt Consider this C program that prints three lines: #include int main() { puts("a\nb"); puts("c"); } If we examine the writes with, say, strace: $ strace -o log -e write ./a.out a b c We might see (here glibc): write(1, "a\n", 2) = 2 write(1, "b\n", 2) = 2 write(1, "c\n", 2) = 2 Yes, glibc takes line buffering quite literally, even splitting writes on a string. Some implementations are a little more sophisticated: write(1, "a\nb\n", 2) = 4 write(1, "c\n", 2) = 2 CPython makes exactly those writes for this program: import sys sys.stdout.write("a\nb\n") sys.stdout.write("c\n") Its rule is to flush if its buffer contains a newline after appen ## CodeQL 2.27.4 improves accuracy and query metadata DevFeed: [CodeQL 2.27.4 improves accuracy and query metadata]() Original publisher: [Read original article]() Author: Allison Published: 2026-11-04T20:04:52Z Content type: release Language: en Sources: [GitHub Changelog]() Topics: [Static code analysis](), [GitHub]() Tags: [analysis](), [application-security](), [arithmetic](), [blog](), [c](), [c-c-plus-plus](), [c-plus-plus](), [c-sharp](), [changelog](), [changes](), [code-scanning](), [codeql](), [engine](), [github](), [improvement](), [improvements](), [metadata](), [post](), [query](), [security](), [static](), [static-analysis]() ### AI overview CodeQL 2.27.4 improves analysis accuracy across several languages: Java/Kotlin queries recognize more sanitizers and path guards; Rust queries have fewer false positives; and C/C++ queries suppress reports for intentional `std::byte*` pointer arithmetic and variables marked `[[maybe_unused]]`. It also removes CWE-730 metadata from specified regex-related queries across C#, Java/Kotlin, JavaScript/TypeScript, Python, Ruby, and Swift. The CLI sends JVM warnings and initialization errors to stderr, preserving machine-readable output. When bundling or publishing packs, it omits files whose resolved symbolic links point outside the pack root and warns about them. GitHub deploys new CodeQL versions automatically for code scanning on github.com; this release is slated for GHES 3.24, while older GHES versions can be upgraded manually. ### Source excerpt CodeQL is the static analysis engine behind GitHub code scanning, which finds and remediates security issues in your code. We've recently released CodeQL 2.27.4 with query accuracy improvements across several... The post CodeQL 2.27.4 improves accuracy and query metadata appeared first on The GitHub Blog. ## A 42-year-old bug patched in C-Kermit DevFeed: [A 42-year-old bug patched in C-Kermit]() Original publisher: [Read original article]() Author: Anne Barela Published: 2026-11-04T15:11:23Z Content type: news Language: en Sources: [Adafruit Industries]() Topics: [Cybersecurity](), [legacy systems]() Tags: [buffer](), [bug](), [c](), [clients](), [code-execution](), [code-quality](), [columbia-university](), [communications](), [cve](), [embedded](), [history](), [kermit](), [legacy](), [network](), [patched](), [remote](), [remote-code-execution](), [reverse-engineering](), [security](), [security-advisories](), [security-fixes](), [serial](), [telnet](), [vintage](), [vintage-computing]() ### AI overview A code-quality review of C-Kermit found several security flaws, including buffer overflows in the telnet and FTP clients, shell injection in two server commands, an IKSD login bypass, and arbitrary file writes during transfers. The oldest flaw dates to C-Kermit 4.0 (1985) and also appears in Unix Kermit from 1984. All releases through 11.0.514 are affected; the supplied text identifies 11.1.515 as the fix. The project's restarted maintainer says real-world risk is low because most users connect over serial lines and the one known public Kermit server is patched. CVE IDs were still being assigned. These findings come from the supplied excerpt. ### Source excerpt sysxplore posted on X about a set of security fixes in C-Kermit, the serial and network communications suite that started at Columbia University in the 1980s. People still use it to talk to embedded, legacy and vintage machines. It just got three security advisories, one of them for remote code execution. John Goerzen restarted the [...] ## Uncertainty-Aware Prototype Learning for Open-Set Test-Time Adaptation DevFeed: [Uncertainty-Aware Prototype Learning for Open-Set Test-Time Adaptation]() Original publisher: [Read original article]() Author: Jinwu Hu, Langyu Bian, Jian Sun, Dongjin Yang, Chao Shuai, Yufeng Wang, Kai Zhou, Bin Xiao, Mingkui Tan, Hongmin Cai, Wei Luo Published: 2026-11-04T05:00:00Z Content type: article Language: en Sources: [arXiv: Artificial Intelligence](), [arXiv: Machine Learning]() Topics: [Machine learning](), [Model Development](), [outlier-detection]() Tags: [benchmarks](), [c](), [class](), [cs-ai](), [cs-lg](), [entropy](), [features](), [learning](), [ood](), [open](), [performance](), [prototype](), [test](), [uncertainty]() ### AI overview UAPA addresses open-set test-time adaptation, where shifted in-distribution (csID) and out-of-distribution (csOOD) samples can appear together and csOOD samples may cause harmful adaptation gradients. It separates them using a classifier-prototype score and a mini-batch-normalized, evidence-derived uncertainty score. It periodically refines class-specific target prototypes from buffered csID features, then minimizes entropy for csID and maximizes it for csOOD; prototype-level contrastive learning pulls csID features toward matching prototypes and limits csOOD similarity to known-class prototypes. The abstract reports average OSCR gains over the strongest baselines of 2.08 percentage points on CIFAR benchmarks and 1.28 points on Tiny-ImageNet-C. ### Source excerpt arXiv:2611.04689v1 Announce Type: new Abstract: Open-set test-time adaptation (TTA) aims to adapt source-trained models to unlabeled test streams where covariate-shifted in-distribution (csID) samples and covariate-shifted out-of-distribution (csOOD) samples may coexist. Existing TTA methods are typically designed under a closed-set assumption and therefore lack explicit mechanisms for reliably distinguishing csID from csOOD samples. Consequently, csOOD samples may be mistakenly included in confidence-enhancing adaptation, producing harmful gradients that degrade known-class performance. To address this, we propose Uncertainty-Aware Prototype Learning for Open-Set Test-Time Adaptation (UAPA), a plug-and-play method for reliable open-set adaptation. Specifically, we first introduce Uncertainty-Driven ID/OOD Separation, which combines a classifier-prototype score with a mini-batch-normalized evidence-derived uncertainty score to distinguish csID from csOOD samples. We then propose a Dynamic Prototype Refinement strategy that periodically refines class-specific target prototypes using buffered csID features to progressively follow the estimated class directions. Lastly, we introduce Contrastive Prototype Entropy Adaptation, which applies entropy minimization to csID samples and entropy maximization to csOOD samples, while prototype-level contrastive learning aligns csID features with their corresponding target prototypes and reduces the maximum similarity between csOOD features and known-class prototypes. Empirically, UAPA outperforms the strongest baselines on the CIFAR benchmarks and Tiny-ImageNet-C, improving average OSCR by 2.08 and 1.28 percentage points, respectively. ## Predicting protein structures at any folding stage from sequence DevFeed: [Predicting protein structures at any folding stage from sequence]() Original publisher: [Read original article]() Author: Lisheng Zhang, Qingsong Li, Zinan Xie, Yanting Yang, Qikui Yang, Peng Lu, Zhican Fu, Wentao Cui, Runtong Hou, Zhengwei Xie Published: 2026-11-04T05:00:00Z Content type: article Language: en Sources: [arXiv: Artificial Intelligence]() Topics: [Machine learning](), [Artificial Intelligence](), [alphafold2]() Tags: [3](), [about](), [abstract](), [all](), [alpha](), [alphafold](), [alphafold-3](), [also](), [arxiv](), [assembly](), [atom](), [away](), [better](), [binning](), [but](), [c](), [coherent](), [cs-ai](), [folding](), [q-bio-bm](), [sequence](), [stage]() ### AI overview FoldScape generates protein Cα conformational ensembles from sequence at a specified folding fraction, covering stages from collapsed coil to near-native globule. It predicts inter-residue distances in sliding windows, assembles chains, and samples structures with a rectified-flow decoder; training uses coarse-grained folding and all-atom mechanical-unfolding trajectories. On 20 human proteins, it covered about an order of magnitude more of the folding coordinate than seed-varied AlphaFold 3 ensembles at matched sample size, with roughly constant reconstruction accuracy across folding stages. AlphaFold 3 better anchors the immediate native vicinity, which FoldScape does not reach, so the methods are complementary. A stride-one crop-and-superpose scheme extends inference to longer chains. The abstract also reports residue-level mechanical-unfolding resolution and coherent partially unfolded segments; these findings are based on the described trajectories and evaluations. ### Source excerpt arXiv:2611.04287v1 Announce Type: cross Abstract: Protein structure predictors reliably identify native conformations, but do not describe the continuum connecting unfolded ensembles to folded states. Here we present FoldScape, a sequence-conditioned deep learning framework that generates C$\alpha$ conformational ensembles at a specified folding fraction $Q$. FoldScape reconstructs three-dimensional chains through hierarchical, sliding-window regressions of one-dimensional inter-residue distances, followed by chain assembly and sampling with a rectified-flow decoder. It is trained on multi-scale coarse-grained folding trajectories and all-atom mechanical-unfolding trajectories. Across 20 human proteins (36-857 residues), at matched sample size, FoldScape covers about an order of magnitude more of the folding coordinate than seed-varied AlphaFold 3 ensembles, robustly across proteins, order parameters and binning choices. AlphaFold 3 better anchors the immediate native vicinity, which FoldScape does not reach, making the approaches complementary. FoldScape reconstruction accuracy remains approximately constant along $Q$, from collapsed coil to near-native globule, rather than deteriorating away from the native state. A stride-one crop-and-superpose scheme extends inference to chains several times longer than a single chain-level forward pass. We also show that training trajectories resolve mechanical unfolding at residue resolution, that elongation-conditioned ensembles exhibit reproducible continuous observables across pulling velocities, and that partially unfolded chains form geometrically coherent segments. FoldScape thus combines broad coverage of folding stages with stable reconstruction accuracy, without per-protein simulation. ## The early history of the UNIX "more" command DevFeed: [The early history of the UNIX "more" command]() Original publisher: [Read original article]() Author: Anne Barela Published: 2026-11-03T20:00:35Z Content type: article Language: en Sources: [Adafruit Industries]() Topics: [Unix](), [Terminal]() Tags: [berkeley](), [bsd](), [c](), [command](), [history](), [less](), [more](), [operating-system](), [program](), [programming](), [terminal](), [uc-berkeley](), [unix](), [vintage-computing]() ### AI overview In 1978, UC Berkeley graduate student Dan Halbert replaced an awkward wait in Berkeley's `cr3` program with the `more` prompt: cr3 printed 24 lines and rang a bell, but ADM-3 terminals' output bells were often disconnected. Halbert's version displayed "-More-" and continued on a space-bar press, following a method he knew from ITS at MIT. Eric Shienbrood and Geoff Peck later added options and prompt responses, and `more` shipped in 3.0 BSD. The excerpt notes that Mark Nudelman wrote `less`, which also scrolls backward, between 1983 and 1985. ### Source excerpt Dan Halbert, writing on danhalbert.org, tells how he came to write the Unix more command in 1978 as a first-year graduate student at UC Berkeley. The piece first ran on comp.society.folklore in 1994 and then in The ANALYTICAL ENGINE. Berkeley already had a small program called cr3 that printed 24 lines and rang the terminal [...] ## Scrutinize our assessments DevFeed: [Scrutinize our assessments]() Original publisher: [Read original article]() Author: Daniel Stenberg Published: 2026-11-03T09:16:17Z Content type: article Language: en Sources: [Daniel Stenberg]() Topics: [vulnerability management](), [cURL](), [issue tracking](), [cve remediation](), [project release]() Tags: [assessment](), [bug](), [c](), [curl](), [curl-and-libcurl](), [cve](), [cwe](), [database](), [github](), [issue-tracker](), [markdown](), [medium](), [metadata](), [public](), [pull-requests](), [release](), [repositories](), [repository](), [security](), [security-advisory](), [vulnerabilities]() ### AI overview curl handles suspected LOW and MEDIUM severity vulnerability reports publicly in GitHub issues. Reports first receive the vuln:ASSESS tag, where anyone can comment; afterward they are classified as vuln:NONE (treated as a bug), vuln:LOW, or vuln:MEDIUM. Reasoned objections can prompt reassessment. Confirmed vulnerabilities get a CVE and a separate advisory in curl-www; fixes are merged when ready, while advisories remain open until publication with the curl release containing the fix. The issue and CVE assignment are public earlier, but the CVE database entry and advisory are published on the release date. ### Source excerpt I recently blogged about how the curl project switched to doing all handling of vulnerabilities at severity LOW and MEDIUM in the public. Let me now describe how you can follow along this process and help out. Add your opinions, comments and assessments to help the curl project stay honest, do even better and manage ... Continue reading Scrutinize our assessments -> ## Proximity Gaps for Gabidulin Codes and Applications DevFeed: [Proximity Gaps for Gabidulin Codes and Applications]() Original publisher: [Read original article]() Author: Songsong Li, Chaoping Xing, Chen Yuan, Ruiqi Zhu Published: 2026-11-03T05:00:00Z Content type: article Language: en Sources: [arXiv: Cryptography and Security]() Topics: [Cryptography]() Tags: [abstract](), [adapting](), [all](), [alpha](), [applications](), [arxiv](), [based](), [c](), [central](), [code](), [coding](), [coding-theory](), [cryptographic](), [cryptography](), [cs-cr](), [cs-it](), [d](), [delta](), [either](), [error](), [error-correcting-codes](), [math-it](), [proximity]() ### AI overview Every linear rank-metric code over $\mathbb F_{q^m}$ has a proximity gap up to $(d-1)/(3n)$, with error at most $q^{e+1}/q^m$ for $e=\lfloor\delta n\rfloor$; Gabidulin codes improve the threshold to $(d-1)/(2n)$ with error $10q^{n-1}/q^m$. The abstract reports that this Gabidulin threshold is tight for an infinite family of constant-rate codes, and gives a matching lower bound on error up to a constant factor. Applications adapt Ligero to build an IOPP for interleaved Gabidulin codes and a commitment scheme for $q$-linearized polynomials, described as the first PCS framework based on rank-metric codes. ### Source excerpt arXiv:2609.09838v2 Announce Type: replace-cross Abstract: Proximity gaps are central to the soundness of interactive oracle proofs of proximity (IOPPs) and polynomial commitment schemes (PCSs). An $[n,k,d]$ linear code $C\subseteq\mathbb F^n$ has a $\delta$-proximity gap with error $\epsilon$ if, for every $u_0,u_1\in\mathbb F^n$, either all points on $\ell_{u_0,u_1}=\{u_0+\alpha u_1:\alpha\in\mathbb F\}$ are $\delta$-close to $C$, or at most an $\epsilon$ fraction are. Although proximity gaps for Hamming-metric codes are well understood, their rank-metric counterparts remain largely unexplored despite their applications in coding theory and cryptography. In this work, we study proximity gaps for linear rank-metric codes and their cryptographic applications. First, we show that every $[n,k,d]$ linear rank-metric code $C$ over $\mathbb F_{q^m}$ admits a proximity gap for every $\delta\le(d-1)/(3n)$, with error at most $q^{e+1}/q^m$, where $e=\lfloor\delta n\rfloor$. For Gabidulin codes, we improve the gap to $(d-1)/(2n)$ with error $10q^{n-1}/q^m$. These two proximity gaps match those for general linear Hamming-metric codes and Reed--Solomon (RS) codes, respectively. We prove the $(d-1)/(2n)$ bound is tight by constructing an infinite family of constant-rate Gabidulin codes and affine lines $\ell_{u_0,u_1}$ on which a $1-o(1)$ fraction of points are $d/(2n)$-close to the code, while $u_1$ is at least $3d/(4n)$-far from it. At $\delta=(d-1)/(2n)$, a further counterexample gives a lower bound of order $q^{n-1}/q^m$ on $\varepsilon$, matching our upper bound up to a constant factor. As applications, we construct an IOPP for interleaved Gabidulin codes by adapting the Ligero IOPP for interleaved RS codes. We then adapt the Ligero-based PCS for ordinary polynomials to obtain a $q$-linearized polynomial commitment scheme. To our knowledge, this is the first PCS framework based on rank-metric error-correcting codes. [Next page]()