# POSIX Published articles for POSIX. This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## Libreboot Build System Audit 5 DevFeed: [Libreboot Build System Audit 5]() Original publisher: [Read original article]() Author: Leah Rowe Published: 2026-09-17T04:32:50.666044Z Content type: article Language: en Sources: [News about Libreboot releases and development]() Topics: [audit](), [opensource](), [boot](), [POSIX](), [ide](), [systems]() Tags: [audit](), [bios](), [bugs](), [canoeboot](), [clean-code](), [coreboot](), [efficiency](), [firmware](), [free-software](), [libre](), [libreboot](), [linux](), [opensource](), [operating-systems](), [posix](), [uefi]() ### AI overview This article describes the fifth audit of Libreboot's lbmk build system, covering changes made since the Libreboot 20240504 release. It reports a reduction in shell-script size, bug fixes, feature changes, and improvements aimed at cleaner and more efficient code. ### Source excerpt Article: Libreboot Build System Audit 5 Web link: https://libreboot.org/news/audit5.html ## Sound Open Firmware 2.15 Released With AMD ACP 7.x Support, Intel UAOL DevFeed: [Sound Open Firmware 2.15 Released With AMD ACP 7.x Support, Intel UAOL]() Original publisher: [Read original article]() Author: Michael Larabel Published: 2026-09-15T13:04:40Z Content type: release Language: en Sources: [Phoronix]() Topics: [Embedded Software Dev](), [Open Source](), [intel](), [Security](), [qemu](), [Xtensa](), [Fuzzing/Fuzz testing](), [POSIX](), [Testing]() Tags: [desktop-linux](), [driver](), [dsp](), [firmware](), [fuzzing](), [intel](), [linux-benchmarking](), [linux-hardware-benchmarks](), [linux-hardware-reviews](), [linux-how-to](), [linux-performance](), [linux-server-benchmarks](), [open](), [open-source-graphics](), [phoronix](), [phoronix-test-suite](), [posix](), [processor](), [qemu](), [security](), [testing](), [ubuntu-benchmarks](), [ubuntu-hardware](), [usb](), [xtensa]() ### AI overview Sound Open Firmware 2.15 adds user-space, memory-protected module execution, AMD ACP 7.x and NXP i.MX8MP support, Intel UAOL USB audio offload, testing targets, security hardening, and new audio processing modules. ### Source excerpt Sound Open Firmware as the open-source, vendor-independent audio DSP firmware stack and driver framework is out today with a new feature update... ## Infineon RISC-V for Automotive at Hot Chips 2026 DevFeed: [Infineon RISC-V for Automotive at Hot Chips 2026]() Original publisher: [Read original article]() Author: Vic A Published: 2026-09-13T21:58:44Z Content type: article Language: en Sources: [ServeTheHome]() Topics: [RISC-V](), [Microcontroller](), [real-time](), [Low Latency](), [Architecture & Design](), [Security](), [IO](), [Inference Performance]() Tags: [2026](), [architecture](), [automotive](), [compute](), [cost](), [efficiency](), [infineon](), [latency](), [low-latency](), [microcontrollers](), [mobile](), [performance](), [posix](), [processors](), [real-time](), [risc-v](), [security]() ### AI overview Infineon presents RISC-V automotive processors for next-generation vehicle architectures. The article covers real-time control, low latency, power efficiency, security, zone controllers, central car computers, and heterogeneous workloads including DSP, AI inference, audio, and POSIX-based services. ### Source excerpt At Hot Chips 2026, Infineon presented a case for using RISC-V in various automotive processors in next-generation cars The post Infineon RISC-V for Automotive at Hot Chips 2026 appeared first on ServeTheHome. ## A quick overview of atomics in C DevFeed: [A quick overview of atomics in C]() Original publisher: [Read original article]() Author: Daniel Lemire Published: 2026-09-09T20:41:53Z Content type: tutorial Language: en Sources: [Daniel Lemire]() Topics: [C](), [Concurrency](), [Concurrent Programming](), [Programming]() Tags: [atomics](), [c](), [join](), [ordering](), [posix](), [programming-language](), [systems](), [thread](), [threads]() ### AI overview This tutorial introduces atomics in C, explaining data races on shared non-atomic variables, atomic accesses, instruction reordering, and memory-ordering models including relaxed, release, and acquire semantics. It also discusses C11 threads and platform support limitations. ### Source excerpt If you write in C, by default, you use a single thread. Extra cores do not help until you create more threads. However, if you include the header , you can pass a function to thrd_create, and wait for it with thrd_join. #include #include int worker(void *arg) { printf("hello from thread %d\n", *(int ... Continue reading A quick overview of atomics in C ## AAOS SDV - Secure by Design DevFeed: [AAOS SDV - Secure by Design]() Original publisher: [Read original article]() Author: Android Developers (noreply@blogger.com) Published: 2026-08-24T16:00:31Z Content type: article Language: en Sources: [Android Developers Blog]() Topics: [Android](), [Security](), [virtualization](), [virtual machines](), [SELinux](), [POSIX](), [Processes](), [Google]() Tags: [android](), [android-security](), [article](), [google](), [posix](), [process](), [security](), [selinux](), [virtual-machines](), [virtualization]() ### AI overview This article explains the security design of Android Automotive Operating System for Software Defined Vehicle (AAOS SDV). It describes virtualization for domain isolation, UID-based application and service sandboxing, POSIX capabilities, SELinux deny-by-default enforcement, and Android's vulnerability management and disclosure processes. ### Source excerpt Posted by Markus Vill, Software Engineer, Sean Keys, Security Engineer, and Istvan Nador, Software Engineer, Android Auto At Google, we believe our products should be secure by design, which is why we built the Android Automotive Operating System for Software Defined Vehicle (AAOS SDV) on existing, market-proven platforms, leveraging virtualization technologies like Cuttlefish. While our release announcements focused on the features, this blog post outlines some of the security concepts. Foundation: Domain IsolationVirtualization to isolate co-hosted instances The current trend of consolidating Electronic Control Units (ECUs) into a single chip reduces isolation by running multiple domains side-by-side. While AAOS SDV instances provide internal isolation mechanisms, it is often preferable to run logical domains independently. For instance, a cluster and an infotainment system have distinct requirements. We use virtual machines to run multiple instances in parallel, ensuring that sharing remains explicit and isolation is the default behavior. Inherited Android Security AAOS SDV evolved from Microdroid, a minimalistic Android version optimized for privacy virtual machines (pVM). This lineage provides Android platform engineers with established security features they already know. Process Isolation & Deny by Default AAOS SDV follows Android's User ID (UID)-based isolation model to set up a sandbox for each application. Each service runs in a dedicated process with a unique UID to manage access rights, data directories, and other restrictions. We employ Portable Operating System Interface (POSIX) capabilities to strictly limit operations and pair this with Security-Enhanced Linux (SELinux) to enforce a "deny-by-default" posture. This approach restricts each service to the absolute minimum required, meaning missing configurations block access rather than creating an over-permissive system. We apply this same strategy to our communication permission system, as explained l ## Vim: por qué merece la pena frente a nano DevFeed: [Vim: por qué merece la pena frente a nano]() Original publisher: [Read original article]() Author: Antonio Pérez Published: 2026-08-01T13:00:00Z Content type: tutorial Language: es Sources: [tengoping.com]() Topics: [Vim](), [POSIX](), [Unix]() Tags: [alpine](), [distro](), [editor](), [posix](), [unix](), [vim]() ### AI overview A practical Spanish tutorial explaining why Vim is worth learning instead of nano. It covers how to exit, save, undo, and redo, then argues that Vim is widely available on Unix systems because vi is required by POSIX. It also discusses BusyBox, Alpine, and Vim's modes. ### Source excerpt Vim parece complicado pero no lo es: aprende a salir, moverte y editar con lo mínimo imprescindible, sin miedo y sin memorizar todo de golpe. ## GNU Hurd Q2 2026 development updates DevFeed: [GNU Hurd Q2 2026 development updates]() Original publisher: [Read original article]() Published: 2026-07-03T20:32:51Z Content type: news Language: en Sources: [GNU Hurd]() Topics: [Code](), [POSIX](), [SVG](), [GitHub](), [virtio](), [Kernel](), [Wiki]() Tags: [2026](), [code](), [crash](), [cross-compilation](), [posix](), [servers](), [svg](), [virtio](), [wiki]() ### AI overview A quarterly GNU Hurd development update covering a public 9pfs repository with basic file browsing and reading support, additional write support, POSIX-related validation, bug fixes, cross-compilation work, Rust translator development, and planned dynamic device population. ### Source excerpt Hello and welcome to another Qoth! Here's what's been happening in Q2 of 2026! Joshua Branson added a pretty cool svg logo for our ethernet multiplexor. He built that image with Inkscape whilst using a Hurd laptop (Thinkpad 420) running on real iron! The Hurd wiki could certainly use more artwork. Perhaps you have a favorite Hurd translator that you believes needs some artwork! Sergey Bugaev announced his WIP 9pfs (source code), and it has a wiki page! He writes: Some years ago, I experimented with implementing a 9P translator for the Hurd. Hopefully there is no need to tell this list what 9P is :) Besides just browsing files on the few existing servers out there, a potential use case is virtio-9p, to enable shared directory trees between VMs and the host. But that would need someone to implement virtio support in the Hurd. I wanted to complete 9pfs before publishing, but that ultimately didn't happen, so now it's time to turn it over to the community. I now went and made the repository public on GitHub: https://github.com/bugaevc/9pfs What's implemented is basic browsing (readdir, stat), path resolution (dir_lookup), and reading files (io_read). And below that, the whole tracking for nodes, peropens, protids, fids, tags, and 9p RPCs. Improvements are welcome, send patches to this list with [PATCH 9pfs] in the subject. A good starting point would be to continue porting things that I had implemented in the old netfs-based version (see netfs.c) but didn't yet port to the new one. He then got a little more motivated, and he added some write support! Etienne Brateau added validation to msync, so that the Hurd better follows POSIX. Diego Nieto Cid worked on allowing privileged users to set their task priority (nice value). His patches landed in glibc and GNU Mach. He also fixed a tiny bug in our test suite. He fixed an adjtime bug, which is helpful to the OpenNTPD port, and he fixed two more bugs. Paulo Duarte sent a RFC patch series trying to commit Sergey's previous AA ## NuttX Web Panel: A self-hosted web interface for NuttX DevFeed: [NuttX Web Panel: A self-hosted web interface for NuttX]() Original publisher: [Read original article]() Author: John Lee Published: 2026-06-29T00:00:00Z Content type: tutorial Language: en Sources: [Blog on Developer Portal]() Topics: [NuttX](), [Self-hosted](), [web applications](), [Python](), [WebSocket](), [Command-line interface](), [Monitoring]() Tags: [apache](), [blog](), [esp32-p4](), [monitoring](), [nuttx](), [posix](), [python](), [self-hosted](), [terminal](), [web](), [web-interface](), [wi-fi]() ### AI overview NuttX Web Panel is a self-hosted web interface that runs on a NuttX device. It combines system monitoring, a browser-based NSH terminal, and file management, including uploading and running Python scripts without recompiling firmware. ### Source excerpt NuttX Web Panel is a self-hosted web interface for NuttX that provides system information, a browser-based NSH terminal, and file management. Combined with Python, it turns NuttX into a computing platform where interpreted applications can be developed and tested without recompiling code. ## Coding Challenge #124 - Du DevFeed: [Coding Challenge #124 - Du]() Original publisher: [Read original article]() Author: John Crickett Published: 2026-06-13T08:01:14Z Content type: tutorial Language: en Sources: [Coding Challenges]() Topics: [Code Challenge](), [POSIX](), [Unix](), [Utility Software](), [Programming]() Tags: [coding](), [exercise](), [filesystem](), [posix](), [programming](), [programming-language](), [run](), [unix](), [utilities]() ### AI overview A coding challenge asks readers to build their own POSIX-compatible du utility. It covers recursively traversing directories, calculating disk usage, handling hard links and symbolic links, and presenting results in multiple formats. ### Source excerpt This challenge is to build your own du. ## ESP-IDF v6.0: Default libc Switches from Newlib to PicolibC DevFeed: [ESP-IDF v6.0: Default libc Switches from Newlib to PicolibC]() Original publisher: [Read original article]() Author: John Lee Published: 2026-04-02T00:00:00Z Content type: article Language: en Sources: [Blog on Developer Portal]() Topics: [ESP-IDF](), [C](), [Embedded Systems](), [migration](), [Streams](), [Library](), [POSIX]() Tags: [apis](), [architectures](), [blog](), [c](), [compatibility](), [embedded](), [embedded-systems](), [esp-idf](), [firmware](), [libc](), [libraries](), [memory](), [migration](), [newlib](), [performance](), [picolibc](), [posix](), [streams](), [systems](), [toolchains]() ### AI overview ESP-IDF v6.0 changes its default C library from Newlib to PicolibC. The article compares the libraries' memory usage, standard I/O behavior, compatibility, and migration considerations, including measurements on ESP32-C3. ### Source excerpt ESP-IDF v6.0 switches the default C library from Newlib to PicolibC. This article compares both libraries in terms of memory usage, stdio behavior, compatibility, and migration tradeoffs, and explains when keeping Newlib still makes sense. ## Java SIGINT Handling: Why Replacing an Internal API Changed Shell Behavior DevFeed: [Java SIGINT Handling: Why Replacing an Internal API Changed Shell Behavior]() Original publisher: [Read original article]() Author: Davide Angelocola Published: 2026-03-27T00:00:00Z Content type: opinion Language: en Sources: [Davide Angelocola]() Topics: [Java](), [POSIX](), [Processes](), [Code]() Tags: [code](), [java](), [jdk](), [jvm](), [posix](), [process](), [risk]() ### AI overview The author describes replacing Java's internal signal-handling API in the hosh interactive shell after stronger module encapsulation in newer JDKs. The replacement used a shutdown hook, which changed Ctrl+C behavior from cancelling the current command while preserving the JVM to terminating the entire process. ### Source excerpt Today I pushed a commit to hosh. The commit message was innocent enough: fix: avoid usage of jdk.internal.Signal. The diff was 20 lines added, 31 removed. And it was wrong -- not syntactically, but semantically. It changed the behavior of my program in a way I didn't fully appreciate until I sat down and thought about what the Java Platform Module System was actually telling me. This is a story about that mistake, and about why I think Java's module system, for all the grief it gets, is one of the best things that happened to the platform. ## Introducing the SPIFFS component DevFeed: [Introducing the SPIFFS component]() Original publisher: [Read original article]() Author: John Lee Published: 2026-03-23T00:00:00Z Content type: tutorial Language: en Sources: [Blog on Developer Portal]() Topics: [ESP-IDF](), [Filesystems](), [Streams](), [C](), [POSIX](), [ESP32]() Tags: [article](), [beginner](), [blog](), [c](), [esp-idf](), [filesystem](), [guide](), [posix](), [spiffs](), [storage](), [tutorial]() ### AI overview This practical guide introduces the SPIFFS component bundled with ESP-IDF for storing files on SPI NOR flash. It explains how SPIFFS works with the VFS layer and standard C and POSIX file APIs, describes features such as wear levelling, consistency checks, and format-on-mount, and outlines a basic flow for mounting, writing, renaming, and reading files. It also points to SPIFFSgen and an official working example. ### Source excerpt Learn what the ESP-IDF SPIFFS component is, how it works with the VFS layer and standard C file APIs, and how to use the SPIFFSgen tool to embed files. This article is a practical guide with references to the official example. ## Power Management in NuttX DevFeed: [Power Management in NuttX]() Original publisher: [Read original article]() Author: John Lee Published: 2026-02-05T00:00:00Z Content type: tutorial Language: en Sources: [Blog on Developer Portal]() Topics: [NuttX](), [Espressif](), [Embedded Systems](), [Embedded Software Dev](), [systems](), [ESP32](), [ESP32-C6]() Tags: [article](), [blog](), [efficiency](), [embedded](), [embedded-systems](), [esp32-c6](), [espressif](), [how-to](), [low-power](), [microcontrollers](), [nuttx](), [posix](), [power-management](), [practitioner]() ### AI overview This tutorial explains power management on Espressif devices using NuttX. It describes Espressif power modes, NuttX power-management states, how the states map to one another, and how to control sleep modes from the shell or a custom application. It also introduces governors and discusses power-consumption measurements across multiple ESP chips. ### Source excerpt This article walks through Espressif power modes and NuttX power states, then explains how they map to each other. Then it introduces NuttX's power management system and the concept of governors. The how-to part shows how to control sleep modes from the shell and a custom application. Finally, you will see real power-consumption measurements across multiple ESP chips to illustrate the practical impact using power states. ## Advanced techniques for porting libraries to ESP-IDF components DevFeed: [Advanced techniques for porting libraries to ESP-IDF components]() Original publisher: [Read original article]() Author: John Lee Published: 2025-11-24T00:00:00Z Content type: tutorial Language: en Sources: [Blog on Developer Portal]() Topics: [ESP-IDF](), [Library](), [AWS IoT Core](), [OpenSSH](), [WebSocket](), [aio](), [CMake](), [make](), [POSIX]() Tags: [blog](), [cmake](), [compiler](), [component](), [components](), [esp-idf](), [feature-flags](), [library](), [linux](), [mqtt](), [porting](), [posix](), [ssh](), [systems](), [techniques]() ### AI overview This follow-up article presents advanced techniques for porting larger libraries, particularly those designed for Linux or POSIX systems, into reusable ESP-IDF components. It covers assessing reusable code, adapting build systems and port layers, configuration, header injection, linker wrapping, and compiler-warning management, with examples including asio, mosquitto, libssh, and libwebsockets. ### Source excerpt This article follows up on the article 'Porting a library to an ESP-IDF component' and shows some advanced tips and tricks when porting larger libraries into ESP-IDF components. ## QEMU at Google Summer of Code Mentor Summit 2025 DevFeed: [QEMU at Google Summer of Code Mentor Summit 2025]() Original publisher: [Read original article]() Author: Stefano Garzarella Published: 2025-11-20T08:00:00Z Content type: news Language: en Sources: [QEMU]() Topics: [qemu](), [Google](), [Open Source](), [macOS](), [Rust](), [POSIX]() Tags: [conferences](), [event](), [germany](), [google-summer-of-code](), [gsoc](), [internships](), [macos](), [open-source](), [posix](), [qemu](), [rust]() ### AI overview A report on the 2025 Google Summer of Code Mentor Summit in Munich, where QEMU mentors discussed open source challenges, mentorship practices, and related projects. The article also describes a GSoC project extending Rust crates for vhost-user devices on macOS and BSD. ### Source excerpt The Google Summer of Code (GSoC) Mentor Summit 2025 took place from October 23rd to 25th in Munich, Germany. This event marks the conclusion of the annual program, bringing together mentors from all over the world. QEMU had another successful year with several interesting projects (details on our organization page), and it was a pleasure for me to represent the QEMU community at the summit, joining mentors from over 100 open source organizations to discuss the program, share experiences, and talk about open source challenges. ## A Higgs-bugson in the Linux Kernel DevFeed: [A Higgs-bugson in the Linux Kernel]() Original publisher: [Read original article]() Author: Nikhil Jha Published: 2025-07-02T00:00:00Z Content type: tutorial Language: en Sources: [Jane Street]() Topics: [bug](), [Kernel](), [Linux](), [debug](), [Filesystems](), [POSIX](), [Security]() Tags: [bug](), [data](), [debug](), [filesystem](), [kernel](), [linux](), [linux-kernel](), [posix](), [security](), [trading]() ### AI overview A Jane Street engineering post investigates a difficult-to-reproduce bug affecting large file copies in Gord, a system that stores and distributes trading activity data. It explains the role of NFS, Kerberos authentication, and Linux kernel credential handling during the debugging process. ### Source excerpt We recently ran across a strange higgs-bugson that manifested itself in a critical system that stores and distributes the firm's trading activity data, called Gord. (A higgs-bugson is a bug that is reported in practice but difficult to reproduce, named for the Higgs boson, a particle which was theorized in the 1960s but only found in 2013.) In this post I'll walk you through the process I took to debug it. I tried to write down relevant details as they came up, so see if you can guess what the bug is while reading along. ## Running Python on ESP32-S3 with NuttX DevFeed: [Running Python on ESP32-S3 with NuttX]() Original publisher: [Read original article]() Author: John Lee Published: 2025-03-07T11:00:00Z Content type: tutorial Language: en Sources: [Blog on Developer Portal]() Topics: [ESP32-S3](), [NuttX](), [Python](), [Programming]() Tags: [apache](), [blog](), [esp32](), [esp32-s3](), [getting-started](), [guide](), [nuttx](), [posix](), [python]() ### AI overview This tutorial explains that Apache NuttX supports the Python interpreter on ESP32-S3 and describes why Python can be useful for embedded applications. It begins a walkthrough for building and running Python on an ESP32-S3 board, with requirements including at least 16 MiB of flash and 8 MiB of external PSRAM. ### Source excerpt Running Python on ESP32-S3 with NuttX# Yes, you heard it right: Apache NuttX now supports the Python interpreter on ESP32-S3! NuttX is a platform that can run applications built with programming languages other than traditional C. C++, Zig, Rust, Lua, BASIC, MicroPython, and, now, Python. Why?# According to the IEEE Spectrum's 11th annual rankings, Python leads as the most utilized programming language among IEEE members, with adoption rates over twice as high as the second-ranked language. ## Converting a UTC Date-Time String to a UNIX Epoch Timestamp in C and C++ DevFeed: [Converting a UTC Date-Time String to a UNIX Epoch Timestamp in C and C++]() Original publisher: [Read original article]() Published: 2025-01-19T15:02:00Z Content type: tutorial Language: en Sources: [Bert Hubert's writings]() Topics: [C](), [POSIX](), [C++]() Tags: [c](), [c-plus-plus](), [posix](), [programming](), [unix](), [utc]() ### AI overview The article examines how to convert a UTC date-time string into a UNIX epoch timestamp in C and C++. It discusses unexpected behavior in POSIX time-handling functions and the complications caused by local times and daylight-saving transitions. ### Source excerpt So how hard could it be. As input we have something like Fri, 17 Jan 2025 06:07:07 in UTC, and we'd like to turn this into 1737094027, the notional (but not actual) number of seconds that have passed since 1970-01-01 00:00:00 UTC. Trying to figure this out led me to discover many 'surprise features' and otherwise unexpected behaviour of POSIX time handling functions as implemented in various C libraries & the languages that build on them. ## "Rules" that terminal programs follow DevFeed: ["Rules" that terminal programs follow]() Original publisher: [Read original article]() Author: Julia Evans Published: 2024-12-12T09:28:22Z Content type: article Language: en Sources: [Julia Evans]() Topics: [Terminal](), [Command-line interface](), [Shell](), [Bash](), [Linux]() Tags: [bash](), [c](), [command-line](), [linux](), [posix](), [terminal](), [utilities]() ### AI overview An exploration of the informal rules and conventions that terminal programs commonly follow, including interrupt handling, quitting interfaces, color output, readline keybindings, and stdin/stdout conventions. ### Source excerpt Recently I've been thinking about how everything that happens in the terminal is some combination of: Your operating system's job Your shell's job Your terminal emulator's job The job of whatever program you happen to be running (like top or vim or cat) The first three (your operating system, shell, and terminal emulator) are all kind of known quantities - if you're using bash in GNOME Terminal on Linux, you can more or less reason about how how all of those things interact, and some of their behaviour is standardized by POSIX. But the fourth one ("whatever program you happen to be running") feels like it could do ANYTHING. How are you supposed to know how a program is going to behave? This post is kind of long so here's a quick table of contents: programs behave surprisingly consistently these are meant to be descriptive, not prescriptive it's not always obvious which "rules" are the program's responsibility to implement rule 1: noninteractive programs should quit when you press Ctrl-C rule 2: TUIs should quit when you press q rule 3: REPLs should quit when you press Ctrl-D on an empty line rule 4: don't use more than 16 colours rule 5: vaguely support readline keybindings rule 5.1: Ctrl-W should delete the last word rule 6: disable colours when writing to a pipe rule 7: - means stdin/stdout these "rules" take a long time to learn programs behave surprisingly consistently As far as I know, there are no real standards for how programs in the terminal should behave - the closest things I know of are: POSIX, which mostly dictates how your terminal emulator / OS / shell should work together. I think it does specify a few things about how core utilities like cp should work but AFAIK it doesn't have anything to say about how for example htop should behave. these command line interface guidelines But even though there are no standards, in my experience programs in the terminal behave in a pretty consistent way. So I wanted to write down a list of "rules" that in my experi ## Using Wokwi with NuttX DevFeed: [Using Wokwi with NuttX]() Original publisher: [Read original article]() Author: John Lee Published: 2024-11-12T23:08:20Z Content type: tutorial Language: en Sources: [Blog on Developer Portal]() Topics: [NuttX](), [simulator](), [Simulation](), [ESP32](), [qemu](), [RISC-V]() Tags: [alternatives](), [apache](), [blog](), [esp32](), [linux](), [nuttx](), [posix](), [qemu](), [real-time](), [risc-v](), [simulation](), [simulator](), [wokwi](), [xtensa]() ### AI overview A tutorial on using the NuttX real-time operating system with the Wokwi simulator. It explains Wokwi's advantages and limitations, compares it with QEMU, and describes compiling NuttX locally before simulating the output on supported ESP32 Xtensa- and RISC-V-based devices. ### Source excerpt In this article, we will examine how the NuttX real-time operating system (RTOS) can be used on the Wokwi simulator, what adjustments need to be made on the NuttX side for this and what advantages the Wokwi simulator offers. Note! Note: Reviewing this article together with NuttX on an emulated ESP32 using QEMU article will help the user to distinguish between the two solutions and to determine the most suitable solution for the needs. ## Linux / UNIX View Only Configuration File Directives ( Uncommented Lines of a Config File ) DevFeed: [Linux / UNIX View Only Configuration File Directives ( Uncommented Lines of a Config File )]() Original publisher: [Read original article]() Author: Vivek Gite Published: 2024-09-21T12:33:38Z Content type: tutorial Language: en Sources: [nixCraft: Linux Tips, Hacks, Tutorials, And Ideas In Blog Format (RSS/FEED)]() Topics: [Linux](), [configuration](), [Unix](), [Command-line interface](), [pattern matching](), [POSIX](), [processing](), [screen](), [nginx]() Tags: [awk](), [bash-shell](), [cli](), [command-line](), [config](), [configuration](), [easy](), [egrep-command](), [grep-command](), [linux](), [operating-systems](), [perl](), [posix](), [regex](), [regular-expressions](), [sed-command](), [server](), [systems](), [unix]() ### AI overview A tutorial on using grep, egrep, sed, awk, and Perl to display uncommented lines from Linux and Unix configuration files. It also covers removing blank lines, handling comments with whitespace, and viewing large files with pagers. ### Source excerpt Most Linux and UNIX-like system configuration files are documented using comments, but sometimes I just need to see a line of configuration text in a config file. How can I view just the uncommented configuration file directives from squid.conf or httpd.conf file? How can I strip out comments and blank lines on a Linux or Unix-like system? Love this? sudo share_on: Twitter - Facebook - LinkedIn - Whatsapp - Reddit The post Linux / UNIX View Only Configuration File Directives ( Uncommented Lines of a Config File ) appeared first on nixCraft. ## Building Applications on NuttX: Understanding the Build System DevFeed: [Building Applications on NuttX: Understanding the Build System]() Original publisher: [Read original article]() Author: John Lee Published: 2024-09-16T00:00:00Z Content type: tutorial Language: en Sources: [Blog on Developer Portal]() Topics: [NuttX](), [Operating system](), [Embedded Software Dev](), [systems]() Tags: [apache](), [applications](), [blog](), [build](), [esp32](), [how-to](), [linux](), [nuttx](), [port](), [posix](), [tutorial]() ### AI overview This article explains how to integrate and build applications in NuttX, including applications ported from other POSIX-compliant systems. It describes the separation between applications and the NuttX kernel, the role of POSIX-compatible APIs, and the NuttX build system and application repository. ### Source excerpt This article shows how to port and build an application form other Posix-compliant systems to NuttX. ## Nix Weekly Recap: 2024-06-30 DevFeed: [Nix Weekly Recap: 2024-06-30]() Original publisher: [Read original article]() Published: 2024-06-30T00:00:00Z Content type: news Language: en Sources: [nixpkgs.news]() Topics: [Nix](), [Security](), [GitHub Actions](), [Self-hosted](), [Proxmox](), [backups](), [Homelab](), [virtualization](), [Xonsh](), [Xontrib](), [Python](), [Shell]() Tags: [backups](), [c-plus-plus](), [github-actions](), [hosting](), [plantuml](), [posix](), [proxmox](), [pull-request](), [python](), [recap](), [security](), [self-hosted](), [self-hosting](), [shell](), [weekly]() ### AI overview The June 30, 2024 Nix weekly recap covers an important Nix security fix, a project for self-hosted GitHub Actions runners, RFC 0146 on package metadata categories, Xonsh xontribs, Proxmox-NixOS general availability, declarative backups using Clan, security fixes, and newly added packages. ### Source excerpt An important Nix security fix, self-hosted GitHub runners with Nix, Proxmox-NixOS, and more! ## Swift Concurrency Waits for No One DevFeed: [Swift Concurrency Waits for No One]() Original publisher: [Read original article]() Published: 2023-12-22T00:00:00Z Content type: article Language: en Sources: [Saagar Jha]() Topics: [Swift](), [Concurrency](), [Concurrent Programming](), [Code](), [API](), [POSIX]() Tags: [api](), [code](), [concurrency](), [concurrent-programming](), [posix](), [swift](), [threads]() ### AI overview The article explains why Swift Concurrency requires careful handling when asynchronous work must be invoked from synchronous code and then awaited. It uses the example of spawning a Task and blocking with a semaphore to illustrate the complexity of preserving task forward progress, while contrasting Swift Concurrency with older concurrency APIs. ### Source excerpt There was once a master engineer who lived by herself in a mystical, far off place, where nourishment flowed freely and the dirt beneath your feet was more valuable than gold. Inaccessible even by foot, only very few could make the trip for a chance at receiving her wisdom. A novice programmer, enthusiastic but still wet behind the ears, visited her one day. "I have read your code," he began, "and I can only describe it as sublime. But, I've been learning a lot about Swift Concurrency and I see that you don't use it all the time. Why is that?" The master engineer replied promptly with a question of her own: "Tell me, how would an asynchronous program call synchronous code?" "That's easy," he replied. "You can just call it directly." "Now, how would one invoke asynchronous code from a synchronous context?" "Spawn a Task, obviously!" replied the novice engineer, glad that his studies had come in handy. The master engineer smiled. "Very good. But now, imagine waiting for the work to complete before proceeding. What then? The API, naturally, is provided by the system and cannot be redesigned." This troubled the novice, and he furrowed his brow in concentration for some time. Finally, a half-forgotten memory came back to him: "DispatchSemaphore! I can use a semaphore to wait for the asynchronous work!" "Swift Concurrency requires tasks to make forward progress", responded the master engineer. Then she fell silent. After a while, the novice was enlightened. [Next page]()