# Specifications A specification is a document that precisely and verifiably defines a system or component's requirements, design, behavior, or other characteristics. This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## AAEON MIX-PTLWV1 Panther Lake industrial mini-ITX motherboard offers quad DisplayPort, dual 10GbE, and more DevFeed: [AAEON MIX-PTLWV1 Panther Lake industrial mini-ITX motherboard offers quad DisplayPort, dual 10GbE, and more]() Original publisher: [Read original article]() Author: Jean-Luc Aufranc (CNXSoft) Published: 2026-09-16T12:00:59Z Content type: news Language: en Sources: [CNX Software - Embedded Systems News]() Topics: [Embedded Systems](), [intel](), [Intel Core](), [ddr5](), [M.2 NVMe](), [pcie](), [Graphics](), [Specifications]() Tags: [10gbe](), [2-5gbe](), [4g-lte](), [5g](), [aaeon](), [artificial-intelligence-ai](), [automotive](), [ddr5](), [graphics](), [hardware](), [industrial](), [intel-core](), [linux](), [m-2-nvme](), [mini-itx](), [motherboard](), [nvme](), [panther-lake](), [pcie](), [single-board-computer](), [smart-city](), [specifications](), [ubuntu](), [windows-11]() ### AI overview CNX Software reports on the AAEON MIX-PTLWV1, an industrial mini-ITX motherboard built around Intel Core Ultra Series 3 Panther Lake processors. It supports up to 128GB of DDR5 memory, NVMe storage, four DisplayPort outputs, optional wireless and cellular modules, multiple Ethernet ports including up to two 10GbE connections, serial interfaces, and PCIe expansion. ### Source excerpt AAEON MIX-PTLWV1 is an industrial mini-ITX motherboard based on Intel Core Ultra Series 3 "Panther Lake" processors with up to two 10GbE and two 2.5GbE RJ45 jacks, and four 4K-capable DisplayPort video outputs. The motherboard also supports up to 128GB DDR5 C/SO-DIMM memory, M.2 NVMe SSD storage, optional WiFi and Bluetooth, and/or 4G LTE/5G cellular via M.2 modules, a PCIe Gen4 x8 slot for expansion, six serial interfaces, 12V-24V wide DC input, and more. AAEON MIX-PTLWV1 specifications: SoC - Intel Panther Lake processor (PTL-H404/PTL-H484 families) with Intel Xe LPG graphics; TDP: 15 to 25W System Memory - Up to 128GB via 2x 262-pin DDR5 C/SO-DIMM sockets up to 6400MHz (H404 SKU) or 7200MHz (H484 SKU) Storage - M.2 2280 M-Key (PCIe Gen4 x4) socket for NVMe SSD Display Interfaces 4x DisplayPort 1.4 up to 4096 x 2160 @ 60Hz 40-pin LVDS/eDP co-layout connector for Default: 18/24 bit dual-channel LVDS up [...] The post AAEON MIX-PTLWV1 Panther Lake industrial mini-ITX motherboard offers quad DisplayPort, dual 10GbE, and more appeared first on CNX Software - Embedded Systems News. ## Designing Libraries and SDKs for Human Developers and Coding Agents DevFeed: [Designing Libraries and SDKs for Human Developers and Coding Agents]() Original publisher: [Read original article]() Author: CommonsWare Published: 2026-08-22T17:08:47Z Content type: opinion Language: en Sources: [The CommonsBlog]() Topics: [SDKs](), [AI-assisted coding](), [Agentic development](), [Documentation](), [test](), [Specifications]() Tags: [agentic](), [blog](), [coding-agents](), [documentation](), [open-source](), [sdk](), [sdks](), [specifications](), [tests]() ### AI overview This opinion article argues that library and SDK authors should support both human developers and coding agents. It recommends clear source-code comments, generated API documentation, robust and runnable test suites, coverage analysis, and language-neutral specifications with conformance tests to clarify intended behavior and support faithful ports. ### Source excerpt Let's explore how we can succeed with libraries and SDKs at a time when coding agents will be consuming what we create, as will ordinary developers ## Sandisk 600 and 800 NAS SSDs Revealed DevFeed: [Sandisk 600 and 800 NAS SSDs Revealed]() Original publisher: [Read original article]() Author: Rob Andrews Published: 2026-08-20T12:00:27Z Content type: news Language: en Sources: [NAS Compares]() Topics: [Hardware](), [NVMe](), [M.2 NVMe](), [Specifications]() Tags: [asustor-ssd](), [m-2-nvme](), [nas-600](), [nas-800](), [nas-drive-ssd](), [nas-hardware](), [nas-ssd](), [network-attached-storage-nas](), [nvme](), [qnap-ssd](), [sandisk](), [sandisk-1000](), [sandisk-200](), [sandisk-2026](), [sandisk-2027](), [sandisk-400](), [sandisk-600](), [sandisk-800](), [sandisk-nas-600](), [sandisk-nas-800](), [sandisk-nas-ssd](), [sandisk-ssd](), [specifications](), [ssd](), [ssd-for-nas](), [ssd-nas-drive](), [synology-ssd](), [ugreen-ssd](), [uncategorised](), [wd-2026](), [wd-2027](), [wd-nas-ssd](), [wd-red-nas-ssd](), [wd-red-ssd]() ### AI overview Sandisk has introduced the NAS 600 and NAS 800 SSD families for NAS systems. The NAS 600 is a 2.5-inch SATA SSD for storage and all-flash arrays, while the NAS 800 is an M.2 2280 PCIe 5.0 NVMe SSD for caching, tiered storage and primary storage in compatible systems. ### Source excerpt New SSDs for NAS Released by Sandisk - Too late? Sandisk has introduced 2 SSD families designed specifically for NAS use, covering both conventional 2.5-inch SATA storage and higher-performance M.2 NVMe applications. The SANDISK NAS 600 and NAS 800 series are intended for prosumers, creative professionals and small businesses using always-on systems for shared storage, [...] ## Xiaomi Smart Storage NAS Revealed DevFeed: [Xiaomi Smart Storage NAS Revealed]() Original publisher: [Read original article]() Author: Rob Andrews Published: 2026-08-03T16:00:11Z Content type: article Language: en Sources: [NAS Compares]() Topics: [Hardware](), [Specifications](), [QNAP](), [Synology]() Tags: [2-bay-nas](), [capacity](), [china](), [consumer](), [crowdfunding](), [hardware](), [home-nas](), [hyperos](), [launch](), [leak](), [nas](), [nas-2026](), [nas-news](), [network-attached-storage-nas](), [news](), [news-2026](), [private-cloud](), [product](), [qnap](), [qnap-2026](), [qnap-alternative](), [qnap-news](), [realtek-rtd1619b](), [specifications](), [storage](), [synology](), [synology-2026](), [synology-alternative](), [synology-news](), [uncategorised](), [xiaomi](), [xiaomi-nas](), [xiaomi-smart-storage](), [xiaomi-youpin]() ### AI overview Xiaomi Smart Storage is a two-bay consumer NAS launched in China through Xiaomi Youpin crowdfunding. The article describes its family-focused storage use cases, bundled-drive pricing, and leaked engineering-sample hardware specifications, while distinguishing official details from unconfirmed specifications. ### Source excerpt Xiaomi has now officially moved into the home NAS market with Xiaomi Smart Storage, a two-bay consumer storage box that is being launched in China through Xiaomi Youpin crowdfunding. The product is being positioned less like a traditional enthusiast NAS and more like a family storage appliance for phone backup, photo management, files, and home [...] ## Which Doc Format is Best for AI Specifications? DevFeed: [Which Doc Format is Best for AI Specifications?]() Original publisher: [Read original article]() Author: Peter Lawrey (noreply@blogger.com) Published: 2026-07-14T14:00:28Z Content type: article Language: en Sources: [Vanilla Java]() Topics: [Specifications](), [Markdown](), [Fable](), [HTML](), [Documentation]() Tags: [ai](), [fable](), [html](), [info](), [markdown](), [readability](), [specifications]() ### AI overview The article compares Markdown, AsciiDoc, and HTML for AI specifications using document-size, markup-overhead, readability, and editing-workflow observations. It recommends Markdown for AI working documents, AsciiDoc for curated human-reviewed specifications, and HTML primarily as a publishing target. ### Source excerpt I have a Spec Driven Project with 674 documents incl 181 specs, 429 tasks, and 40 project docs. About 1/3 of these are an acceptance sub-project to show the root project meets fit-for-purpose requirements. I used Fable to convert these to and from AsciiDoc, Markdown, and HTML. From this, I tried to draw some conclusions about which format is better than the others for AI specifications. TL;DR: Markdown for AI working documents, AsciiDoc for curated human-reviewed specs, HTML only as a publishing target. Objective Metrics Corpus Tokens (Approx) Markdown: 594k, AsciiDoc: 598K, HTML: 661k Worst Single-File Ratio AsciiDoc: 1.023x, HTML: 1.26x (due to tables and code blocks) Markup share of file content Markdown 0.9%, AsciiDoc 1.3%, HTML 9.9% - a 10x overhead for HTML Read/write Assessment In terms of readability, both Markdown and AsciiDoc are good. HTML has far more tags, which add noise. One of the most common tags is some code however in the other formats, this is just `some code` When you have an average of 16 per file, this adds a lot of noise. Usability GitHub renders both Markdown and AsciiDoc with working links and checkboxes; HTML is shown as raw source, so the review loop dies there. The first two are also easier to view while you're editing in IntelliJ. HTML is more difficult to read and edit, and it is not as easy to view the rendered output. If you occasionally need HTML, you don't need HTML files: embed an island with ```{=html} in Markdown (Pandoc raw-attribute syntax) or in AsciiDoc. It renders where HTML is supported and drops out cleanly elsewhere. If you really need to use HTML, you can include a link to a file in that format. Note As these were one-for-one conversions, I didn't use features that only exist in AsciiDoc or HTML, such as. Markdown vs AsciiDoc While you might choose either format for your specs, I have been following this convention to keep the authoring consistent. Markdown used for AI-generated content, not human-written, ## A sufficiently comprehensive spec is not (necessarily) code DevFeed: [A sufficiently comprehensive spec is not (necessarily) code]() Original publisher: [Read original article]() Author: Hillel Wayne Published: 2026-04-15T16:18:02Z Content type: opinion Language: en Sources: [Newsletter feed for Hillel Wayne's Newsletter]() Topics: [Specifications](), [implementation](), [Claude Code](), [Code](), [Large Language Model]() Tags: [claude-code](), [code](), [implementation](), [llms](), [specifications]() ### AI overview The article argues that a sufficiently comprehensive specification is not necessarily code. A specification describes a set of possible implementations, while code is one implementation within that set; even specifications used with Claude Code can leave important design decisions unresolved. ### Source excerpt Sorry for missing last week! Was sick and then busy. This week I want to cover a pet peeve of mine, best seen in this comic: A "comprehensive and precise spec" is not necessarily code. A specification corresponds to a set of possible implementations, and code is a single implementation in that set. As long as the set has more than one element, there is a separation between the spec and the code. Consider a business person (bp) who asks: I want a tool to convert miles to kilometers. Is this a comprehensive spec? Maybe, you can give it to Claude Code and tell it to make all design decisions and it will give you a program that converts miles to km. At the same time, there is a huge amount of details left out of this. What language? What's the UX? Should it be a command line script or a mobile app or an enterprise SaaS? For this reason, if we gave Claude's output to the bp, they'll probably be unsatisfied. The set of possible implementations includes the programs they want, but also lots of programs they don't want. So they now they say: It should be a textbox on a website. Okay, this rules out a lot more stuff, but there's still a lot to decide. React or vanillajs or htmx? Should the output be a separate textbox or a popup? Should we use a conversion of 1.6, 1.61, or 1.609? So you could argue that this is still not a "comprehensive and precise spec". But what if the bp is happy with whatever Claude makes? Then their spec was sufficiently comprehensive and precise, since they got a program that solved their problem! Now the comic above makes the more specific claim that a spec "comprehensive and precise enough to generate a program" is code. That wasn't even true before LLMs. Program synthesis, the automatic generation of conformant programs from specifications, is an active field of research! Last I checked in 2019 they were only generating local functions from type specifications; I don't know how things have changed with LLMs. But still, it shows that code and compre ## LLMs are bad at vibing specifications DevFeed: [LLMs are bad at vibing specifications]() Original publisher: [Read original article]() Author: Hillel Wayne Published: 2026-03-10T17:12:30Z Content type: article Language: en Sources: [Newsletter feed for Hillel Wayne's Newsletter]() Topics: [Formal methods](), [Large Language Model](), [Specifications](), [Artificial Intelligence]() Tags: [ai](), [formal-methods](), [llms](), [nondeterminism](), [specifications](), [verification]() ### AI overview The article examines AI-generated TLA+ and Alloy specifications through a case study. It argues that these specifications may fail to compile or model-check and often contain tautological or obvious properties rather than subtle properties involving concurrency, nondeterminism, or multi-step bad behavior. ### Source excerpt No newsletter next week I'll be speaking at InfoQ London. But see below for a book giveaway! LLMs are bad at vibing specifications About a year ago I wrote AI is a gamechanger for TLA+ users, which argued that AI are a "specification force multiplier". That was written from the perspective an TLA+ expert using these tools. A full 4% of Github TLA+ specs now have the word "Claude" somewhere in them. This is interesting to me, because it suggests there was always an interest in formal methods, people just lacked the skills to do it. It's also interesting because it gives me a sense of what happens when beginners use AI to write formal specs. It's not good. As a case study, we'll use this project, which is kind of enough to have vibed out TLA+ and Alloy specs. Looking at a project Starting with the Alloy spec. Here it is in its entirety: module ThreatIntelMesh sig Node {} one sig LocalNode extends Node {} sig Snapshot { owner: one Node, signed: one Bool, signatures: set Signature } sig Signature {} sig Policy { allowUnsignedImport: one Bool } pred canImport[p: Policy, s: Snapshot] { (p.allowUnsignedImport = True) or (s.signed = True) } assert UnsignedImportMustBeDenied { all p: Policy, s: Snapshot | p.allowUnsignedImport = False and s.signed = False implies not canImport[p, s] } assert SignedImportMayBeAccepted { all p: Policy, s: Snapshot | s.signed = True implies canImport[p, s] } check UnsignedImportMustBeDenied for 5 check SignedImportMayBeAccepted for 5 Couple of things to note here: first of all, this doesn't actually compile. It's using the Boolean standard module so needs open util/boolean to function. Second, Boolean is the wrong approach here; you're supposed to use subtyping. sig Snapshot { owner: one Node, - signed: one Bool, signatures: set Signature } + sig SignedSnapshot in Snapshot {} pred canImport[p: Policy, s: Snapshot] { - s.signed = True + s in SignedSnapshot } So we know the person did not actually run these specs. This is somewhat less of a probl ## Stream of Consciousness Driven Development DevFeed: [Stream of Consciousness Driven Development]() Original publisher: [Read original article]() Author: Hillel Wayne Published: 2026-02-18T16:33:08Z Content type: opinion Language: en Sources: [Newsletter feed for Hillel Wayne's Newsletter]() Topics: [Development](), [Specifications](), [Markdown]() Tags: [concepts](), [development](), [experience](), [markdown](), [pairing](), [specifications]() ### AI overview The author describes a pairing technique for conceptually complex specification work: write the problem, discussion, rejected approaches, proposed solution, and rationale in a Markdown file before changing the specification. This helps partners understand the reasoning and agree on an approach, though the author reports having tried it only once. ### Source excerpt This is something I just tried out last week but it seems to have enough potential to be worth showing unpolished. I was pairing with a client on writing a spec. I saw a problem with the spec, a convoluted way of fixing the spec. Instead of trying to verbally explain it, I started by creating a new markdown file: NameOfProblem.md Then I started typing. First the problem summary, then a detailed description, then the solution and why it worked. When my partner asked questions, I incorporated his question and our discussion of it into the flow. If we hit a dead end with the solution, we marked it out as a dead end. Eventually the file looked something like this: Current state of spec Problems caused by this Elaboration of problems What we tried that didn't work Proposed Solution Theory behind proposed solution How the solution works Expected changes Other problems this helps solve Problems this does *not* help with Only once this was done, my partner fully understood the chain of thought, and we agreed it represented the right approach, did we start making changes to the spec. How is this better than just making the change? The change was conceptually complex. A rough analogy: imagine pairing with a beginner who wrote an insertion sort, and you want to replace it with quicksort. You need to explain why the insertion sort is too slow, why the quicksort isn't slow, and how quicksort actually correctly sorts a list. This could involve tangents into computational complexity, big-o notation, recursion, etc. These are all concepts you have internalized, so the change is simple to you, but the solution uses concepts the beginner does not know. So it's conceptually complex to them. I wasn't pairing with a beginning programmer or even a beginning specifier. This was a client who could confidently write complex specs on their own. But they don't work on specifications full time like I do. Any time there's a relative gap in experience in a pair, there's solutions that are concep ## Proving What's Possible DevFeed: [Proving What's Possible]() Original publisher: [Read original article]() Author: Hillel Wayne Published: 2026-02-11T18:36:53Z Content type: opinion Language: en Sources: [Newsletter feed for Hillel Wayne's Newsletter]() Topics: [Formal methods](), [Specifications](), [Math and Logic](), [systems]() Tags: [flow](), [formal-methods](), [specifications](), [state](), [statement]() ### AI overview A formal methods consultant introduces possibility properties for reasoning about what can happen in a system, distinguishing them from safety and liveness properties. Using temporal-logic notation and examples involving databases and state machines, the article describes possibility and reachability properties and combinations such as always possible and eventually possible. ### Source excerpt As a formal methods consultant I have to mathematically express properties of systems. I generally do this with two "temporal operators": A(x) means that x is always true. For example, a database table always satisfies all record-level constraints, and a state machine always makes valid transitions between states. If x is a statement about an individual state (as in the database but not state machine example), we further call it an invariant. E(x) means that x is "eventually" true, conventionally meaning "guaranteed true at some point in the future". A database transaction eventually completes or rolls back, a state machine eventually reaches the "done" state, etc. These come from linear temporal logic, which is the mainstream notation for expressing system properties. 1 We like these operators because they elegantly cover safety and liveness properties, and because we can combine them. A(E(x)) means x is true an infinite number of times, while A(x => E(y) means that x being true guarantees y true in the future. There's a third class of properties, that I will call possibility properties: P(x) is "can x happen in this model"? Is it possible for a table to have more than ten records? Can a state machine transition from "Done" to "Retry", even if it doesn't? Importantly, P(x) does not need to be possible immediately, just at some point in the future. It's possible to lose 100 dollars betting on slot machines, even if you only bet one dollar at a time. If x is a statement about an individual state, we can further call it a reachability property. I'm going to use the two interchangeably for flow. A(P(x)) says that x is always possible. No matter what we've done in our system, we can make x happen again. There's no way to do this with just A and E. Other meaningful combinations include: P(A(x)): there is a reachable state from which x is always true. A(x => P(y)): y is possible from any state where x is true. E(x && P(y)): There is always a future state where x is true a ## Review of the Self-Defining Systems proposal for AI-driven system development DevFeed: [Review of the Self-Defining Systems proposal for AI-driven system development]() Original publisher: [Read original article]() Author: Aleksey Charapko Published: 2026-01-30T01:24:00Z Content type: opinion Language: en Sources: [Aleksey Charapko]() Topics: [systems](), [Artificial Intelligence](), [Specifications](), [Processes]() Tags: [agentic](), [agents](), [ai](), [changes](), [improvements](), [llm](), [one-page-summary](), [papers](), [performance](), [research](), [specifications](), [systems]() ### AI overview The article reviews Self-Defining Systems, a proposal in which agentic engineers design and build systems from system and operating-environment specifications. It argues that the proposal extends the familiar try, evaluate, and repeat loop by allowing agents to change the specification as well as implement it, while noting that the paper lacks a precise definition of the process. ### Source excerpt Self-Defining Systems (SDS) by Thomas Anderson, Ratul Mahajan, Simon Peter, and Luke Zettlemoyer is a bold proposal for AI-driven systems research. In SDS, agentic "engineers" get the system specification and operating environment specification, then design and build the systems to spec. Crucially, as the specification or environment changes, an army of agents should notice and [...] ## Spec-Driven Development in Practice: How AI Simplify Full-Stack Java DevFeed: [Spec-Driven Development in Practice: How AI Simplify Full-Stack Java]() Original publisher: [Read original article]() Author: Simon Martinelli Published: 2025-12-14T03:03:46Z Content type: tutorial Language: en Sources: [Java Advent Calendar]() Topics: [Spec Driven Development](), [Specifications](), [Artificial Intelligence](), [Requirements](), [Java](), [Spring Boot]() Tags: [2025](), [ai](), [full-stack](), [java](), [spec-driven-development](), [spring-boot]() ### AI overview The article explains Spec-Driven Development and the AI Unified Process (AIUP) for a full-stack Java application using Spring Boot, jOOQ, and Vaadin. It presents requirements, an entity model, and system use cases as ordered specification artifacts from which AI can generate code, tests, and documentation. ### Source excerpt AI is changing how we build software, but many teams still work as if nothing has changed. They treat code as the only reliable artifact. Everything else slowly gets outdated: AI code generation tools can make this even worse if used without structure. They produce code fast, but the process behind the code remains the [...] The post Spec-Driven Development in Practice: How AI Simplify Full-Stack Java appeared first on JVM Advent. ## Keycloak 26.4.0 released DevFeed: [Keycloak 26.4.0 released]() Original publisher: [Read original article]() Author: Keycloak Team Published: 2025-09-30T00:00:00Z Content type: release Language: en Sources: [Keycloak Blog]() Topics: [Keycloak](), [Passkeys](), [Security](), [OAuth 2.0](), [Specifications](), [SPIFFE](), [Kubernetes](), [OpenID connect (OIDC)](), [REST API](), [Availability]() Tags: [authentication](), [idm](), [kerberos](), [keycloak](), [keycloak-release](), [kubernetes](), [ldap](), [oauth](), [oauth-2-0](), [oidc](), [openid-connect](), [release](), [rest-api](), [saml](), [security](), [specifications](), [spiffe](), [sso](), [version]() ### AI overview Keycloak 26.4.0 introduces passkeys, federated client authentication using SPIFFE or Kubernetes service account tokens, support for final FAPI 2.0 specifications, and full DPoP support. The release also includes availability and administration improvements. ### Source excerpt To download the release go to Keycloak downloads. Highlights This release features new capabilities focused on security enhancements, deeper integration, and improved server administration. The highlights of this release are: Passkeys for seamless, passwordless authentication of users. Federated Client Authentication to use SPIFFE or Kubernetes service account tokens for client authentication. Simplified deployments across multiple availability zones to boost availability. FAPI 2 Final: Keycloak now supports the final specifications of FAPI 2.0 Security Profile and FAPI 2.0 Message Signing. DPoP: The OAuth 2.0 Demonstrating Proof-of-Possession at the Application Layer (DPoP) is now fully supported. Improvements include the ability to bind only refresh tokens for public clients, and securing all Keycloak endpoints with DPoP tokens. Read on to learn more about each new feature. If you are upgrading from a previous release, review also the changes listed in the upgrading guide. Security and Standards Passkeys integration (supported) Passkeys are now seamlessly integrated in the Keycloak login forms using both conditional and modal UIs. To activate the integration in the realm, go to Authentication, Policies, Webauthn Passwordless Policy and switch Enable Passkeys to enabled. For more information, see Passkeys. FAPI 2 Final (supported) Keycloak has support for the latest versions of FAPI 2 specifications. Specifications FAPI 2.0 Security Profile and FAPI 2.0 Message Signing are already promoted to Final and Keycloak supports them. Keycloak client policies support the final versions and corresponding client profiles for FAPI 2 are passing the FAPI conformance test suite. Apart from some very minor polishing of existing policies, Keycloak has new client profiles (fapi-2-dpop-security-profile and fapi-2-dpop-message-signing) for the clients that use DPoP and are intended to be FAPI 2 compliant. Thank you to Takashi Norimatsu for contributing this. For more details, see the ## November 2024 Pine64 Community Update Introduces the PineCam and Covers Other Projects DevFeed: [November 2024 Pine64 Community Update Introduces the PineCam and Covers Other Projects]() Original publisher: [Read original article]() Published: 2024-11-21T00:00:00Z Content type: article Language: en Sources: [Community blog on PINE64]() Topics: [Hardware](), [Single Board Computer](), [SOC](), [RISC-V](), [Linux](), [webcam](), [Specifications]() Tags: [avaota-a1](), [camera](), [community-update](), [hardware](), [linux](), [ox64](), [pinecam](), [pinedio](), [pinenote](), [pinetab-v](), [risc-v](), [single-board-computer](), [soc](), [specifications](), [usb]() ### AI overview Pine64's November 2024 community update introduces the PineCam, a successor to the PineCube based on the Oz64 single-board computer and SG2000 SoC. It also provides updates on other Pine64 projects and community activities. ### Source excerpt Welcome back to a new monthly Pine64 community update! This month we are announcing a couple of new products including a SBC and a successor to the PineCube. We have updates to share about the PineNote and the PineDio USB adapter this month along with a talk by one of our community members Dsimic. Table of contents PineCam Yuzuki Avaota-A1 PineNote Attention to all users who have ordered/received a PineNote For general users wanting to purchase a PineNote PineNote News PineTab-V BarCamp Talk About Pine64 and Ox64 Handout PineDio Community content Monthly community updates Want to contribute to the next community update? PineCam Authors: Lukasz, Caffeine The first new device we will be introducing this update is the PineCam! The PineCam is a successor to the PineCube IP camera, but with a much more polished design, better specifications and more features. While the PineCube didn't achieve the success the project had hoped for, we believe it wasn't due to a lack of interest in such hardware, but rather the way it was executed. We've gathered feedback, learned from what went wrong, and have gone back to the drawing board. This time, the PineStore have decided to take a different approach, using a System-on-Chip (SoC) already in our hardware lineup. The device includes more RAM (compared to the PineCube's 128MB), and utilizes a camera interface that "just works". The PineCam is based on the oz64 single board computer which is powered by the SG2000 system on a chip found in the new Oz64. The SOC includes two RISC-V cores (C906 @1Ghz + C906 @700Mhz) and one ARM core (Cortex-A53 @1Ghz). You can find more information on the specifications of the Oz64 and the SOC it's using here. The device features 512MB of RAM, providing just enough memory to run a full Linux-based OS such as MotionEyeOS, a popular surveillance camera operating system. Specific to the PineCam now, the device includes a 2MP camera module which is the same one found in the PineTab 2/-V (the GalaxyCore GC02M2 ## Centered Slider in Jetpack Compose DevFeed: [Centered Slider in Jetpack Compose]() Original publisher: [Read original article]() Author: sinasamaki Published: 2024-11-08T18:06:10Z Content type: tutorial Language: en Sources: [sinasamaki]() Topics: [Jetpack Compose](), [ui](), [implementation](), [User experience (UX)](), [Specifications]() Tags: [article](), [design](), [implementation](), [jetpack-compose](), [snap](), [specifications](), [ui](), [ux]() ### AI overview This tutorial explains how to build a customizable centered slider in Jetpack Compose based on Material 3 slider behavior. It covers a configurable center value, snapping near the center, center indicators, and distinct active and inactive visual sections. ### Source excerpt Creating a glowy centered slider based on the material 3 slider ## Updating Twelve-Factor: A Call for Participation DevFeed: [Updating Twelve-Factor: A Call for Participation]() Original publisher: [Read original article]() Author: Vish Abrams Published: 2024-08-28T22:39:00Z Content type: article Language: en Sources: [Heroku]() Topics: [Specifications](), [Software as a service](), [Cloud Native Ecosystem](), [AI Platform](), [Kubernetes]() Tags: [cloud-native](), [developer-tools](), [events](), [kubernetes](), [microservices](), [modern-apps](), [news](), [saas](), [specifications]() ### AI overview Heroku invites the community to help update the Twelve-Factor App methodology by removing outdated technology references, modernizing examples, and separating core concepts from examples and reference implementations. ### Source excerpt Over a decade ago, Heroku co-founder Adam Wiggins published the Twelve-Factor App methodology as a way to codify the best practices for writing SaaS applications. In that time, cloud-native has become the default for all new applications, and technologies like Kubernetes are widespread. Best-practices for software have evolved, and we believe that Twelve-Factor also needs [...] The post Updating Twelve-Factor: A Call for Participation appeared first on Heroku. ## Importance of writing in the engineering industry DevFeed: [Importance of writing in the engineering industry]() Original publisher: [Read original article]() Author: TheAnkurTyagi Published: 2024-02-19T12:12:49Z Content type: opinion Language: en Sources: [ByteSizedBets]() Topics: [Software Engineering](), [Specifications](), [coding style](), [Slack]() Tags: [coding-style](), [engineering](), [slack](), [software-engineering](), [specifications]() ### AI overview This article argues that writing is essential in software engineering because teams rely on written communication for alignment, code reviews, technical specifications, and code. It recommends prioritizing product specifications, technical specifications, and coding style guides, particularly in mid-sized organizations. ### Source excerpt Spoiler: It's very important! ## Goerli Shapella Announcement DevFeed: [Goerli Shapella Announcement]() Original publisher: [Read original article]() Author: EF Protocol Support Published: 2023-03-08T00:00:00Z Content type: news Language: en Sources: [Ethereum Foundation Blog]() Topics: [Ethereum](), [upgrade](), [Network](), [API](), [Specifications]() Tags: [announcement](), [ethereum](), [network](), [protocol-announcements](), [upgrade]() ### AI overview The Shapella network upgrade is scheduled to activate on the Goerli testnet on March 14, 2023. The upgrade enables validators to withdraw their stake from the Beacon Chain to the execution layer and introduces changes to the execution layer, consensus layer, and Engine API. ### Source excerpt Withdrawals are coming! The Shapella network upgrade will activate on the Goerli network at epoch 162304, scheduled for 10:25:36 PM UTC on Mar. 14, 2023 Stakers & node operators should read this post as well as the Withdrawals FAQ The Zhejiang testnet can be used to test Shapella functionality prior... ## FAPI-SIG - a Keycloak's community DevFeed: [FAPI-SIG - a Keycloak's community]() Original publisher: [Read original article]() Author: Takashi Norimatsu Published: 2022-07-01T00:00:00Z Content type: article Language: en Sources: [Keycloak Blog]() Topics: [Keycloak](), [API](), [OAuth 2.0](), [Security](), [openid](), [Specifications]() Tags: [api](), [banking](), [community](), [healthcare](), [idm](), [kerberos](), [keycloak](), [ldap](), [oauth-2-0](), [openid](), [openid-connect](), [saml](), [security](), [specifications](), [sso](), [standards](), [tests]() ### AI overview This article introduces FAPI-SIG, a Keycloak community focused on supporting and validating Financial-grade API security profiles. It describes automated conformance testing for FAPI and other OpenID Foundation standards, and notes Keycloak certifications in several profiles and regions. ### Source excerpt Hello everybody, I am Takashi Norimatsu, a keycloak maintainer. In this article, I would like to introduce you FAPI-SIG, a Keycloak's community. We welcome everyone to join FAPI-SIG. What is FAPI-SIG? The Financial-grade API Special Interest Group (FAPI-SIG) is a Keycloak's community whose aim is to support security features called Financial-grade API (FAPI) security profiles to Keycloak. FAPI-SIG was established in Aug 2020. FAPI security profiles are the open security specifications for secure API access using OAuth 2.0. They are standardized by OpenID Foundation (OID-F), the standardization organization about digital identity. For example, it standardized OpenID Connect. FAPI security profiles are for accessing an API that requires high security level. As its name suggests (Financial), they are originally intended to be used for securely accessing an API providing financial services (e.g., retrieving the balance of a user's bank account, initiating payment). However, also as its name suggests (Financial-grade), these can be used for other types of an API that requires the same security level (e.g., in healthcare industries, retrieving a user's medical records). By supporting FAPI security profiles, Keycloak can be applied in a wide range of use cases that requires high security level about API access (e.g., open banking). FAPI-SIG not only aim to support FAPI security profiles to Keycloak but confirm that Keycloak conforms to FAPI security profiles by using the conformance suite of FAPI security profiles officially provided by OID-F. FAPI-SIG has created the environment for automatically running FAPI security conformance tests. Whenever a new version of Keycloak is released, FAPI-SIG checks if it still complies with FAPI security profiles by using the environment. Therefore, FAPI-SIG contributes to keeping every version of Keycloak compliant to FAPI security profiles. FAPI-SIG start working on supporting security standards defined by OID-F other than FAPI securit ## Supporting adaptive themed icons on Android 13 DevFeed: [Supporting adaptive themed icons on Android 13]() Original publisher: [Read original article]() Author: Siddhesh Patil Published: 2022-05-19T11:50:55Z Content type: tutorial Language: en Sources: [Sid Patil - Android Engineer and Kotlin Advocate]() Topics: [Android](), [android-13](), [material-you](), [implementation](), [personalization](), [Specifications](), [ui]() Tags: [adaptive](), [adaptive-icons](), [android](), [android-13](), [android-13-features](), [android-system-ui](), [android-tiramisu](), [articles-by-sid-patil](), [icons](), [implementation](), [kotlin](), [material-you](), [md3](), [migrate](), [migrating-apps-to-android-tiramisu](), [migrating-to-android-13](), [monet](), [monet-theming](), [personalization](), [specifications](), [support](), [supporting-themed-icons-on-android-13](), [system-ui-apk](), [themed-icons](), [tiramisu](), [ui]() ### AI overview A tutorial on adding adaptive themed icon support to Android applications targeting Android 13 (Tiramisu). It explains the role of Material You and Monet, and identifies Android 13, device-maker Monet support, launcher support, and app-level support as requirements. ### Source excerpt One of the coolest features of Android 13 with Material You and Monet is dynamically themed icons. Let us take a look at how we can migrate our apps to Tiramisu and add support for custom themed icons to match the system wide dynamic theme colors. ## Acceptance Criteria: From Informal Text to Formal Specifications DevFeed: [Acceptance Criteria: From Informal Text to Formal Specifications]() Original publisher: [Read original article]() Author: Artur Dryomov Published: 2019-01-20T00:00:00Z Content type: opinion Language: en Sources: [Artur Dryomov]() Topics: [Agile](), [Requirements](), [Cucumber](), [Specifications]() Tags: [agile](), [communication](), [requirements](), [specifications]() ### AI overview The article discusses Acceptance Criteria as a communication artifact between business and technical teams. It traces their evolution from informal text and email to formal specifications, highlighting Cucumber's Gherkin syntax as a structured option. ### Source excerpt Cooperation! It sure sounds better than bureaucracy. A released product is a result of cooperation between the Business and the Tech. There is an obvious issue though. Both sides have different mindsets. The misunderstanding is inevitable. How do we solve this? Well, there are still wars on the planet so apparently humanity wasn't able to find a solution. What about establishing not world peace but a good communication channel? Agile methodologies establish such artifact as Acceptance Criteria (AC). AC is a specification for how the product should work. Sounds good and the motivation is solid, but there is a catch -- there are no explicit requirements. AC can consist of memes and be distributed by birds -- the sky is the limit (literally). Let's take a look at the evolution and trace our path to the bureaucracy nirvana. ## Easy Approach to Requirements Syntax and the segue to Behavior Driven Development DevFeed: [Easy Approach to Requirements Syntax and the segue to Behavior Driven Development]() Original publisher: [Read original article]() Author: {"twitter"=\>"hlaueriksson"} Published: 2017-07-31T20:00:00Z Content type: article Language: en Sources: [Henrik Lau Eriksson]() Topics: [Requirements](), [Behavior-driven development](), [Specifications](), [User Stories]() Tags: [bdd](), [complexity](), [event](), [feature](), [features](), [format](), [precision](), [requirements](), [simple](), [specflow](), [specifications](), [state](), [test](), [user-stories]() ### AI overview The article introduces Easy Approach to Requirements Syntax (EARS) as a structured way to write requirements and examines how its templates may help translate user stories and acceptance criteria into Behavior-Driven Development tests. It describes five requirement types and the problems EARS aims to reduce, including ambiguity, vagueness, complexity, omission, duplication, wordiness, inappropriate implementation detail, and untestability. ### Source excerpt I was attending a conference six months ago and listened to a talk about quality. During the talk, I was introduced to EARS -- Easy Approach to Requirements Syntax. This way of writing requirements struck a chord with me, given my prior experience reading and writing requirement specifications. ## Visual Specifications DevFeed: [Visual Specifications]() Original publisher: [Read original article]() Published: 2013-10-26T10:56:50Z Content type: opinion Language: en Sources: [Blog by Michael Dubakov]() Topics: [Specifications](), [Agile](), [Software](), [bug]() Tags: [agile](), [bug](), [software](), [specifications]() ### AI overview The article examines why software specifications are often difficult to write and poorly received. It contrasts lightweight Agile requirements with detailed documentation and describes two developer attitudes toward specifications, arguing that the right approach depends on team conditions and communication. ### Source excerpt Why most software specifications suck and how to improve them ## C++ Name Mangling and Compiler ABI Compatibility DevFeed: [C++ Name Mangling and Compiler ABI Compatibility]() Original publisher: [Read original article]() Published: 2011-03-14T00:00:00Z Content type: article Language: en Sources: [Front Page on ReactOS Website]() Topics: [C++](), [Compiler](), [Specifications](), [Exception](), [ReactOS]() Tags: [c-plus-plus](), [code](), [compiler](), [exception](), [exception-handling](), [free](), [open-source](), [os](), [react](), [reactos](), [specifications](), [win32](), [winapi]() ### AI overview The article explains how C++ compilers handle name mangling and exception handling, noting that these behaviors are not fully specified by the C++ standard. It describes compatibility problems when linking code built with different compilers or compiler versions, including differences between GCC, Visual Studio, and other toolchains. ### Source excerpt C++ Mangling Those with any experience using third party libraries while writing C++ applications should quickly recognize the topic I am about to go over and can skip down to paragraph three for the ReactOS specific miseries. Those that are not familiar with the issues or want a refresher should continue. The C++ standard outlines behavior for C++ code when compiled. To be considered a compliant compiler requires following the specifications laid out, though no compiler that I am aware of actually implements 100% of the entire standard.