# x86-64 Published articles for x86-64. This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## Amazon Linux 2027 Enters Public Preview with SELinux Enforcing by Default DevFeed: [Amazon Linux 2027 Enters Public Preview with SELinux Enforcing by Default]() Original publisher: [Read original article]() Author: Steef-Jan Wiggers Published: 2026-09-15T03:40:00Z Content type: news Language: en Sources: [InfoQ]() Topics: [Linux](), [SELinux](), [migration](), [Amazon Web Services](), [Kernel](), [amazon]() Tags: [amazon](), [amazon-linux-2027-preview](), [architecture](), [architecture-design](), [aws](), [cloud](), [development](), [devops](), [ec2](), [infrastructure](), [kernel](), [linux](), [migration](), [news](), [operating-systems](), [preview](), [selinux](), [x86-64]() ### AI overview AWS has released Amazon Linux 2027 in public preview with SELinux enforcing by default. The change may require application and migration work because policies that only logged violations on AL2023 can block applications on AL2027. The release has no announced AL2023 end-of-support date, general-availability date, or in-place migration path. ### Source excerpt AWS has released Amazon Linux 2027 in public preview, built on the AL2023 baseline with kernel 7.1 and SELinux in enforcing mode by default. Applications that pass on AL2023's permissive mode may fail under enforcing. The announcement gives no AL2023 end-of-support date, no GA date, and no in-place migration path. By Steef-Jan Wiggers ## 2.5x Faster x86\_64 Linux Builds on macOS with Rosetta DevFeed: [2.5x Faster x86\_64 Linux Builds on macOS with Rosetta]() Original publisher: [Read original article]() Author: Jacek Galowicz Published: 2026-08-10T00:00:00Z Content type: article Language: en Sources: [Nixcademy Blog]() Topics: [macOS](), [Nix](), [virtualization](), [qemu](), [x86](), [Linux]() Tags: [apple-silicon](), [install](), [macos](), [qemu](), [rosetta](), [run](), [virtualization](), [x86-64]() ### AI overview The article explains a new nix-darwin Linux builder backend that uses Apple's Virtualization.framework and exposes Rosetta to guest VMs. On Apple Silicon Macs, it supports x86_64 Linux builds and is reported to be roughly 2.5 times faster than QEMU-based emulation. ### Source excerpt Build x86_64 Linux packages 2.5x faster on your Apple Silicon Mac with the new Rosetta-based linux-builder, a drop-in replacement in nix-darwin. ## NixOS 26.05 released DevFeed: [NixOS 26.05 released]() Original publisher: [Read original article]() Author: NixOS Published: 2026-05-30T07:00:00Z Content type: release Language: en Sources: [NixOS Announcements]() Topics: [Nix](), [Linux](), [releases](), [Release notes](), [systemd](), [configuration](), [modules](), [deprecated](), [Package manager]() Tags: [2026](), [accessibility](), [configuration](), [deprecated](), [end-of-life](), [gcc](), [linux](), [llvm](), [macos](), [modules](), [nix](), [nixos](), [release](), [release-notes](), [systemd](), [x86-64]() ### AI overview NixOS 26.05, named "Yarara," is publicly available as a new Linux distribution release. The announcement covers package, module, configuration, systemd initrd, platform-support, GNOME, and compiler changes, along with support timelines for NixOS 26.05 and the previous 25.11 release. ### Source excerpt Hey everyone, we are yayayayaka and jopejoe1, the release managers of the newest release of NixOS. We are very proud to announce the public availability of NixOS 26.05 "Yarara". NixOS is a Linux distribution. Its underlying package repository Nixpkgs can also be used on other Linux systems and macOS with the Nix package manager. This release will receive bugfixes and security updates for seven months (up until 2026-12-31). The old release 25.11 "Xantusia" is now officially deprecated and will reach its end-of-life and stop receiving security updates after 2026-06-30. NixOS Release Notes Highlights New Modules Backward Incompatibilities Other Notable Changes Nixpkgs Release Notes Highlights Backward Incompatibilities Other Notable Changes Nixpkgs Library Upgrade Instructions ISO Image Downloads The 26.05 release was made possible due to the efforts of 2842 contributors, who authored 59703 commits since the previous release. Highlights Our vast and routinely maintained set of packages has also been updated. This release of Nixpkgs Added 20442 new packages Updated 20641 existing packages Removed 17532 outdated packages, in an effort to keep the package set maintainable and secure. In addition to packages from Nixpkgs, the NixOS Linux distribution also features composable configuration modules and integration tests for distributed systems. This release of NixOS Added 85 new modules and 1547 configuration options Removed 25 outdated modules and 355 configuration options. systemd stage 1 Stage 1 (a.k.a. initrd) is now based on systemd by default, and the old scripted implementation is deprecated and scheduled for removal in 26.11. Deprecation of x86_64-darwin This will be the last release of Nixpkgs to support x86_64-darwin. Platform support will be maintained and binaries built until Nixpkgs 26.05 goes out of support at the end of 2026. For 26.11, due to Apple's deprecation of the platform and limited build infrastructure and developer time, we will no longer build packa ## How to run Terraform providers not meant for Apple Silicon with Rosetta DevFeed: [How to run Terraform providers not meant for Apple Silicon with Rosetta]() Original publisher: [Read original article]() Author: Tom Published: 2026-05-06T00:00:00Z Content type: tutorial Language: en Sources: [Tomasz Gągor]() Topics: [Terraform](), [x86](), [Arm]() Tags: [apple-silicon](), [architecture](), [bash](), [mac-m1](), [macos](), [provider-checksum](), [rosetta](), [terraform](), [tfenv](), [x86](), [x86-64]() ### AI overview A tutorial explains how to use Rosetta to run Terraform as x86_64 on Apple Silicon, allowing Terraform to download and use providers that do not yet support ARM and helping avoid provider checksum mismatches. ### Source excerpt Use Rosetta to run Terraform as x86_64 on Apple Silicon and avoid provider checksum mismatches. ## Ubuntu variant optimized with x86-64-v3 DevFeed: [Ubuntu variant optimized with x86-64-v3]() Original publisher: [Read original article]() Author: Tom Published: 2026-04-04T00:00:00Z Content type: tutorial Language: en Sources: [Tomasz Gągor]() Topics: [Ubuntu](), [x86](), [Optimization](), [Linux]() Tags: [amd64v3](), [apt-configuration](), [avx](), [cpu](), [cpu-optimization](), [linux](), [linux-performance](), [optimization](), [performance](), [sse](), [ubuntu](), [ubuntu-25-10](), [ubuntu-26-04](), [x86-64](), [x86-64-v3]() ### AI overview This tutorial explains Ubuntu's x86-64-v3 optimized package variant, including its rationale, compatibility considerations, and availability for testing in Ubuntu 25.10. It also discusses plans to extend the approach to Ubuntu 26.04 LTS. ### Source excerpt Explore how to enable and use the x86-64-v3 optimized Ubuntu variant for better performance on modern hardware without sacrificing stability. ## The 64-bit Hurd is Here! DevFeed: [The 64-bit Hurd is Here!]() Original publisher: [Read original article]() Author: Janneke Nieuwenhuizen, Yelninei Published: 2026-03-01T10:00:00Z Content type: article Language: en Sources: [GNU Guix -- Blog]() Topics: [x86](), [bug](), [patches](), [gcc]() Tags: [bug](), [gcc](), [gnu-hurd](), [patches](), [x86](), [x86-64]() ### AI overview Guix has added x86_64 support for the Hurd. The article reviews roughly 1.5 years of related work, including installer support, build and dependency fixes, package updates, and the merge of the 64-bit Hurd changes. ### Source excerpt Fifteen months have passed since our last Guix/Hurd on a Thinkpad X60 post and a lot has happened with respect to the Hurd . And most of you will have guessed, unless you skipped the title of this post, the rumored x86_64 support has landed in Guix! Here is a not-so-short overview of our Hurd work over the past 1.5 years: The build daemon fails when invoking guix authenticate on the Hurd bug was fixed. This was our most pressing problem as it meant that we could not keep... ## Call relocation types DevFeed: [Call relocation types]() Original publisher: [Read original article]() Published: 2026-02-16T08:00:00Z Content type: article Language: en Sources: [MaskRay]() Topics: [x86](), [Assembly](), [Code]() Tags: [architectures](), [binutils](), [function](), [linker](), [static-linking](), [symbols](), [x86](), [x86-64]() ### AI overview This technical post explains why some architectures use separate ELF relocation types for direct function calls and tail calls. It contrasts static linking, where a PC-relative relocation can often be reused, with dynamic linking, where calls may use PLT indirection and therefore require relocation types that encode call semantics. ### Source excerpt Most architectures encode direct branch/call instructions with a PC-relative displacement. This post discusses a specific category of branch relocations: those used for direct function calls and tail calls. Some architectures use two ELF relocation types for a call instruction: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 # i386, x86-64 call foo # R_386_PC32, R_X86_64_PC32 call foo@plt # R_386_PLT32, R_X86_64_PLT32 # m68k bsr.l foo # R_68K_PC32 bsr.l foo@plt # R_68K_PLT32 # s390/s390x brasl %r14, foo # R_390_PC32DBL brasl %r14, foo@plt # R_390_PLT32DBL # sparc call foo, 0 # not PIC: R_SPARC_WDISP30 call foo, 0 # gas -KPIC: R_SPARC_WPLT30 ## Frankenwine: Multiple personas in a Wine process DevFeed: [Frankenwine: Multiple personas in a Wine process]() Original publisher: [Read original article]() Published: 2026-01-19T21:51:38Z Content type: article Language: en Sources: [Chris Wellons]() Topics: [WINE](), [Linux](), [Processes](), [toolchain](), [C](), [Assembly](), [Git]() Tags: [assembly](), [c](), [git](), [linux](), [processes](), [toolchain](), [win32](), [wine](), [x86](), [x86-64]() ### AI overview This article describes building a Windows binary that behaves as a native pkg-config program on Windows but adopts a Linux-program persona when run under Wine. It detects Wine, invokes Linux system calls directly through x86-64 inline assembly, and applies the approach to u-config as a cross-toolchain pkg-config implementation. ### Source excerpt I came across a recent article on making Linux system calls from a Wine process. Windows programs running under Wine are still normal Linux processes and may interact with the Linux kernel like any other process. None of this was surprising, and the demonstration works just as I expect. Still, it got the wheels spinning and I realized an almost practical application: build my pkg-config implementation such that on Windows pkg-config.exe behaves as a native pkg-config, but when run under Wine this same binary takes the persona of a Linux program and becomes a cross toolchain pkg-config, bypassing Win32 and talking directly with the Linux kernel. Cosmopolitan Libc cleverly does this out-of-the-box, but in this article we'll mash together a couple existing sources with a bit of glue. The results are in the merge-demo branch of u-config, and took hardly any work: $ git show --stat ... main_linux_amd64.c | 8 ++--- main_wine.c | 101 +++++++++++++++++++++++++++++++++++++++++ src/linux_noarch.c | 16 ++++----- src/u-config.c | 1 + 4 files changed, 114 insertions(+), 12 deletions(-) A platform layer, main_wine.c, is a merge of two existing platform layers, one of which required unavoidable tweaks. We'll get to those details in a moment. First we'll need to detect if we're running under Wine, and the best solution I found was to locate ntdll!wine_get_version. If this function exists, we're in Wine. That works out to a pretty one-liner because ntdll.dll is already loaded: bool running_on_wine() { return GetProcAddress(GetModuleHandleA("ntdll"), "wine_get_version"); } An x86-64 Linux syscall wrapper with thorough inline assembly: ptrdiff_t syscall3(int n, ptrdiff_t a, ptrdiff_t b, ptrdiff_t c) { ptrdiff_t r; asm volatile ( "syscall" : "=a"(r) : "a"(n), "D"(a), "S"(b), "d"(c) : "rcx", "r11", "memory" ); return r; } ptrdiff_t write(int fd, void *buf, ptrdiff_t len) { return syscall3(SYS_write, fd, (ptrdiff_t)buf, len); } I'd normally use long for all these integers because Linux i ## Remarks on SFrame DevFeed: [Remarks on SFrame]() Original publisher: [Read original article]() Published: 2025-09-28T07:00:00Z Content type: article Language: en Sources: [MaskRay]() Topics: [Linux](), [Compiler](), [Optimization](), [x86]() Tags: [compiler](), [linker](), [linux](), [llvm](), [optimization](), [profiling](), [sframe](), [x86-64]() ### AI overview An analysis of SFrame, a stack-walking format for userspace profiling inspired by Linux's ORC unwind format. It examines SFrame's trade-offs against .eh_frame and Windows ARM64 unwind codes, its section layout, versioning, and opportunities to reduce data-structure overhead. ### Source excerpt SFrame is a new stack walking format for userspace profiling, inspired by Linux's in-kernel ORC unwind format. While SFrame eliminates some .eh_frame CIE/FDE overhead, it sacrifices functionality (e.g., personality, LSDA, callee-saved registers) and flexibility, and its stack offsets are less compact than .eh_frame's bytecode-style CFI instructions. In llvm-project executables I've tested on x86-64, .sframe section is 20% larger than .eh_frame. It also remains significantly larger than highly compact schemes like Windows ARM64 unwind codes. SFrame describes three elements for each function: Canonical Frame Address (CFA): The base address for stack frame calculations Return address Frame pointer An .sframe section follows a straightforward layout: Header: Contains metadata and offset information Auxiliary header (optional): Reserved for future extensions Function Descriptor Entries (FDEs): Array describing each function Frame Row Entries (FREs): Arrays of unwinding information per function ## Preview: Slice Up Bare-Metal with Slicer DevFeed: [Preview: Slice Up Bare-Metal with Slicer]() Original publisher: [Read original article]() Author: Alex Ellis Published: 2025-08-30T08:09:48Z Content type: release Language: en Sources: [Alex Ellis' Blog]() Topics: [Firecracker](), [Kubernetes](), [OpenFaaS](), [systemd](), [Arch Linux](), [Arm](), [migration](), [Ollama]() Tags: [arm](), [bare-metal](), [boot](), [deploy](), [firecracker](), [k3s](), [kubernetes](), [linux](), [network](), [preview](), [self-hosting](), [slicer](), [storage](), [systemd](), [testing](), [work](), [x86-64]() ### AI overview OpenFaaS Ltd is previewing Slicer, an internal tool that partitions bare-metal hosts into Firecracker microVMs. The article describes use cases including Kubernetes cluster scaling, customer simulations, chaos testing, production troubleshooting, Arm and x86_64 testing, persistent workloads, multi-host deployments, and GPU access for Ollama. ### Source excerpt The easiest and best supported way to learn and deploy Firecracker and microVMs. ## Carl Bialorucki hired to improve ReactOS test suite DevFeed: [Carl Bialorucki hired to improve ReactOS test suite]() Original publisher: [Read original article]() Published: 2025-07-04T00:00:00Z Content type: release Language: en Sources: [Front Page on ReactOS Website]() Topics: [Testing](), [Development](), [Windows](), [Kernel](), [WINE](), [x86]() Tags: [2025](), [automated](), [crashes](), [development](), [free](), [open-source](), [os](), [project](), [pull-requests](), [react](), [reactos](), [testing](), [win32](), [winapi](), [windows](), [wine](), [x86](), [x86-64]() ### AI overview Carl Bialorucki announces a full-time contract with ReactOS Deutschland e.V. to improve ReactOS's test infrastructure. The work targets failures, crashes, hangs, and bugchecks in kernel-mode and user-mode tests on newer Windows versions and x86 and x86_64 systems, while syncing Wine tests to Wine 10.0. ### Source excerpt Hi, my name is Carl J. Bialorucki. I started making a name for myself in the ReactOS community by contributing several shell improvements. In May of 2024 I was added to the core development team and in March of 2025 I led the release of ReactOS 0.4.15 after the previous release manager was unable to continue working on the project. I'm pleased to announce that I was hired for a full-time contract position with ReactOS Deutschland e.V. in May of 2025. ## Mitigating a rsync Vulnerability: A Lesson in Compiler Hardening DevFeed: [Mitigating a rsync Vulnerability: A Lesson in Compiler Hardening]() Original publisher: [Read original article]() Published: 2025-03-19T00:00:00Z Content type: article Language: en Sources: [Chainguard: Unchained]() Topics: [Compiler](), [chainguard](), [Security](), [c/c++](), [vulnerability]() Tags: [c](), [c-plus-plus](), [chainguard](), [compiler-flags](), [compiler-hardening](), [cves](), [defense-in-depth](), [hardening](), [linux](), [llvm](), [product-security](), [rsync](), [security](), [x86-64]() ### AI overview Chainguard describes how compiler hardening in its C/C++ toolchain helped protect against an rsync vulnerability before public disclosure. The article presents compiler hardening flags as layers of defense for memory-unsafe software and discusses Chainguard's implementation of recommendations from OpenSSF and GCC. ### Source excerpt Chainguard's defense-in-depth security strategy protected against multiple rsync CVEs before they were even reported. See how we did it, using compiler flags. ## Blog: Introducing Falco 0.40.0 DevFeed: [Blog: Introducing Falco 0.40.0]() Original publisher: [Read original article]() Published: 2025-01-28T00:00:00Z Content type: release Language: en Sources: [Falco - Falco](), [Falco - The Falco blog]() Topics: [Falco](), [Docker](), [Processes](), [Usability](), [Security]() Tags: [bug-fixes](), [docker](), [docker-images](), [falco](), [improvements](), [new-features](), [performance](), [process](), [release](), [version](), [x86-64]() ### AI overview Falco 0.40.0 introduces streamlined Docker images, a reintroduced static x86_64 build using musl, process metadata filters, support for sendmmsg and recvmmsg syscall parameters, and plugin-suggested output fields. The release also includes performance, usability, and bug-fix improvements, along with breaking changes for upgraders. ### Source excerpt Dear Falco Community, today we are happy to announce the release of Falco 0.40.0! This version brings several new features, performance improvements, and bug fixes that streamline Falco's detection capabilities. During this release cycle, we merged more than 52 PRs on Falco and more than 150 PRs for libs and drivers, version 0.20.0 and version 8.0.0 respectively. Thank you to our maintainers and contributors, as this would not happen without your support and dedication! To learn all about these changes, read on! What's new? TL;DR Key features: Streamlined Falco docker images; Falco static build has been reintroduced for x86_64 binary using musl; New process filters allow to filter events based on process metadata; Added support for sendmmsg and recvmmsg syscalls parameters; Plugins suggested output fields are now available in the Falco engine; This release also comes with breaking changes that you should be aware of before upgrading. Major features and improvements The 0.40.0 release contains a number of features and UX improvements. Here is a list of some of the key new capabilities. Streamlined Falco docker images In the Falco 0.40.0 release, the Falco team has streamlined the Docker images to improve usability and performance. The new images are designed to be more efficient and easier to use, providing a better experience for users deploying Falco in containerized environments. Key improvements include: Reduced Image Size: The new images are smaller, which reduces the time required to pull and deploy them. Optimized Layers: The layers in the Docker images have been optimized to improve build times and caching efficiency. Enhanced Security: The images have been hardened to enhance security, reducing potential vulnerabilities. These changes make it easier to deploy and manage Falco in various environments. Introducing new process filters A new set of process filters are made available in this release: proc.pgid, proc.pgid.name, proc.pgid.exe, proc.pgid.exepath, pr ## Building Multiarch Images with Chainguard Images DevFeed: [Building Multiarch Images with Chainguard Images]() Original publisher: [Read original article]() Published: 2024-12-03T00:00:00Z Content type: tutorial Language: en Sources: [Chainguard: Unchained]() Topics: [Docker](), [chainguard images](), [Dockerfile](), [Containers](), [Go Language](), [Graviton](), [GitHub Actions](), [Open Source](), [RISC-V]() Tags: [architecture](), [arm](), [chainguard](), [chainguard-images](), [ci-cd](), [cloud](), [compilation](), [container-image](), [container-images](), [containers](), [cross-compilation](), [docker](), [github](), [github-actions](), [graviton](), [multi-arch](), [multiplatform](), [open-source](), [qemu](), [risc-v](), [single-arch](), [x86-64]() ### AI overview A tutorial on converting single-architecture Docker builds into multi-architecture images using Chainguard Images. It compares QEMU emulation, cross-compilation, and native runners for ARM64 and x86-64 builds, with examples using a Go application and GitHub Actions. ### Source excerpt Looking to turn a single-arch Docker build into a multi-arch? See how you can do that while still using Chainguard Images. ## How to run x86-64 Docker images on Apple's MacBook with M1/M2/M3 CPU DevFeed: [How to run x86-64 Docker images on Apple's MacBook with M1/M2/M3 CPU]() Original publisher: [Read original article]() Author: Tom Published: 2024-02-06T00:00:00Z Content type: tutorial Language: en Sources: [Tomasz Gągor]() Topics: [Docker](), [docker images](), [cpu](), [virtualization]() Tags: [docker](), [docker-cross-platform](), [docker-default-platform](), [docker-images](), [mac](), [macbook-m1-docker](), [macbook-m2-docker](), [macbook-m3-docker](), [macos](), [net-11](), [terminal](), [virtualization](), [x86-64](), [x86-64-docker-images]() ### AI overview A tutorial explains how to run x86-64 Docker images on Apple MacBooks with M1, M2, or M3 CPUs by setting the DOCKER_DEFAULT_PLATFORM environment variable. It notes that this uses virtualization and is slower than native execution. ### Source excerpt Learn how to run x86-64 Docker images on Apple's MacBook with M1/M2/M3 CPUs by setting the DOCKER_DEFAULT_PLATFORM environment variable. ## GNU/Hurd Development Updates for Q3 2023 DevFeed: [GNU/Hurd Development Updates for Q3 2023]() Original publisher: [Read original article]() Published: 2024-01-01T22:22:00Z Content type: news Language: en Sources: [GNU Hurd]() Topics: [systems](), [Git](), [Rust](), [Debian](), [x86](), [networking](), [debugging](), [Remote Procedure Call (RPC)]() Tags: [debian](), [debugging](), [git](), [networking](), [patches](), [rpc](), [rust](), [x86-64]() ### AI overview A quarterly update on GNU/Hurd development in Q3 2023, covering PCI arbiter changes, Rust porting, PAE work, progress on the X86_64 port, build fixes, networking and dpkg fixes, and debugging-tool limitations. ### Source excerpt Hello! Welcome to a new qoth. This qoth covers new and interesting GNU/Hurd developments in Q3 of 2023! Details. Joan Lledo modified the PCI arbiter to prevent mapping I/O region files. He previously sent some patches to implement mapping region and ROM files using mmap(). However, a BAR region can represent either memory or I/O space, and only memory should be allowed to be mapped. Since I/O BARs only contain I/O addresses, he went ahead and prevented the mapping of I/O region files. The next step is to make IO spaces available for users through the pci-arbiter. He plans to add a new RPC that checks for permission and calls i386_io_perm_create(). Then it returns the resulting port. Our Google summer of code student Vedant Tewari decided to port rust, and the rust porting effort is making good progress. The build process is a bit wonky, and Debian is using an older rust version. Check out the rust pull request that adds Hurd support! Samuel worked on setting up PAE, which will eventually let us use more than 4GB of RAM on a 32-bit Hurd! It is also useful for the X86_64 architecture. He also fixed the jemalloc build. Samuel was incredibly productive this quarter making the X86_64 bit port more stable. He fixed the 64-bit Hurd PIE build, and he got git working on the 64-bit port! Though a few of the git tests are failing on both X86_64 and the 32 bit port. He fixed the glibc build, which involved fixing pmap_remove and pmap_protect. He discovered that core dumping is currently causing problems on the 64-bit port, and he temporarily encourages people to disable core dumping. Samuel fixed some networking issues and a dpkg issue for the 64-bit port. It was hard to discover what the problem was, because the debugging tools have not been ported to the 64-bit port. He add some helpers to locking to fix some bugs, and he encourages other developers to help him fix the debugging tools for X86-64. It seems that most developers are currently running the 64-bit Hurd in a virtual ## TensorFlow 2.15 update: hot-fix for Linux installation issue DevFeed: [TensorFlow 2.15 update: hot-fix for Linux installation issue]() Original publisher: [Read original article]() Author: TensorFlow Blog (noreply@blogger.com) Published: 2023-12-05T22:00:00Z Content type: release Language: en Sources: [The TensorFlow Blog]() Topics: [pip](), [Linux](), [TensorRT](), [CUDA](), [Python]() Tags: [announcement](), [dependencies](), [explore](), [installation](), [keras](), [linux](), [nvdia](), [nvidia](), [packages](), [release](), [tensorflow](), [tensorflow-core](), [tensorrt](), [update](), [x86-64]() ### AI overview TensorFlow released version 2.15.0.post1 to fix Linux x86_64 installation problems caused by missing TensorRT-related Python dependencies when installing TensorFlow 2.15 with NVIDIA CUDA dependencies via pip. The hotfix restores the intended installation behavior, while users pinning versions must specify 2.15.0.post1 explicitly. ### Source excerpt Posted by the TensorFlow team We are releasing a hot-fix for an installation issue affecting the TensorFlow installation process. The TensorFlow 2.15.0 Python package was released such that it requested tensorrt-related packages that cannot be found unless the user installs them beforehand or provides additional installation flags. This dependency affected anyone installing TensorFlow 2.15 alongside NVIDIA CUDA dependencies via pip install tensorflow[and-cuda]. Depending on the installation method, TensorFlow 2.14 would be installed instead of 2.15, or users could receive an installation error due to those missing dependencies. To solve this issue as quickly as possible, we have released TensorFlow 2.15.0.post1 for the Linux x86_64 platform. This version removes the tensorrt Python package dependencies from the tensorflow[and-cuda] installation method. Support for TensorRT is otherwise unaffected as long as TensorRT is already installed on the system. Now, pip install tensorflow[and-cuda] works as originally intended for TensorFlow 2.15. Using .post1 instead of a full minor release allowed us to push this release out quickly. However, please be aware of the following caveat: for users wishing to pin their Python dependency in a requirements file or other situation, under Python's version specification rules, tensorflow[and-cuda]==2.15.0 will not install this fixed version. Please use ==2.15.0.post1 to specify this exact version on Linux platforms, or a fuzzy version specification, such as ==2.15.*, to specify the most recent compatible version of TensorFlow 2.15 on all platforms. ## Chainguard Image now available for Pulumi DevFeed: [Chainguard Image now available for Pulumi]() Original publisher: [Read original article]() Published: 2023-06-29T00:00:00Z Content type: release Language: en Sources: [Chainguard: Unchained]() Topics: [pulumi](), [Infrastructure as code](), [container images](), [Security]() Tags: [apko](), [container-images](), [iac](), [multi-arch](), [pulumi](), [security](), [trivy](), [wolfi](), [x86-64]() ### AI overview Chainguard announces a Pulumi container image packaged with the Pulumi toolchain in Wolfi OS and built using apko. The image supports multiple programming-language runtimes, is multi-architecture, and is reported to be smaller and to have fewer Trivy-reported CVEs than the official Pulumi image. ### Source excerpt See a 57% reduction in your Pulumi image sizes with more security built in by default and a 97% reduction in CVEs with the new Chainguard Pulumi Image. ## Chainguard Images now available to government agencies on U.S. Air Force Platform One DevFeed: [Chainguard Images now available to government agencies on U.S. Air Force Platform One]() Original publisher: [Read original article]() Published: 2023-04-18T00:00:00Z Content type: news Language: en Sources: [Chainguard: Unchained]() Topics: [chainguard](), [chainguard images](), [supply-chain-security](), [container images](), [DevSecOps](), [Containers](), [Kubernetes](), [Infrastructure as code]() Tags: [arm](), [chainguard](), [chainguard-images](), [container](), [container-images](), [devsecops](), [glibc](), [government](), [iron-bank](), [node](), [platform-one](), [python](), [sbom](), [software-supply-chain](), [software-supply-chain-security](), [vulnerabilities](), [wolfi](), [x86-64]() ### AI overview Chainguard Images, including Python and Node images, are now available to U.S. government agencies through the U.S. Air Force's Platform One and its authorized Iron Bank container repository. The article explains how Wolfi and Chainguard Images support hardened, lightweight containers with build-time SBOMs, reproducible builds, reduced vulnerabilities, and faster deployments. ### Source excerpt Wolfi has been accepted into Platform One, U.S. Air Force's DevSecOps platform. Chainguard Images are now available on Platform One via container repo Iron Bank ## KVM builds supported on nixbuild.net DevFeed: [KVM builds supported on nixbuild.net]() Original publisher: [Read original article]() Author: support@nixbuild.net Published: 2021-10-01T00:00:00Z Content type: release Language: en Sources: [nixbuild.net blog]() Topics: [Nix](), [builds](), [CI/CD](), [Testing](), [GitHub Actions](), [x86]() Tags: [builds](), [ci-cd](), [github-actions](), [kvm](), [testing](), [x86-64]() ### AI overview nixbuild.net announces early access support for KVM-based builds. The feature enables NixOS integration tests, is initially available only on x86_64-linux, and is supported in the nixbuild.net GitHub Action. ### Source excerpt Less than two weeks ago, we announced support for ARM builds on nixbuild.net. Today we are excited to announce another early access feature -- support for builds that use KVM! KVM support is something that almost no public CI/CD provider offers, so we are very happy to be able to make this available to our users. For NixOS users and developers, this is especially valuable since it makes it possible to run integration tests based on the powerful testing framework found in nixpkgs/NixOS. KVM builds are currently in an Early Access phase. If you want to try it out, contact us at support@nixbuild.net. Anyone is free to request access, but there might be waiting time depending on interest. During Early Access, KVM builds are priced and handled exactly as standard builds. The final pricing and price model for builds that require KVM has not been settled yet. So far KVM builds are only supported on x86_64-linux, not on ARM. Setup Once you've gained access to running KVM builds, configuring your Nix client is simple. You just need to mark your eu.nixbuild.net remote builder with the kvm system feature. And if you want to run NixOS integration tests you'll need the nixos-test feature too. For more detailed configuration descriptions see the documentation. KVM builds in GitHub Actions The nixbuild.net GitHub Action has been updated to support KVM builds too. If you've been granted access to KVM builds, all you have to do is to make sure you use the latest release of nixbuild-action. No extra configuration is needed to run KVM builds, or NixOS integration tests, in GitHub Actions. ## Cross compiling for Apple Silicon with Swift Package Manager DevFeed: [Cross compiling for Apple Silicon with Swift Package Manager]() Original publisher: [Read original article]() Author: Keith Smiley Published: 2020-12-24T22:32:00Z Content type: article Language: en Sources: [Keith Smiley]() Topics: [Swift](), [Package manager](), [macOS](), [x86](), [Xcode](), [Command-line interface](), [Linux]() Tags: [apple](), [architecture](), [architectures](), [binaries](), [build](), [command-line](), [linux](), [macos](), [performance](), [swift](), [swift-package](), [swift-package-manager](), [x86](), [x86-64](), [xcode]() ### AI overview This article explains how to cross-compile Swift Package Manager command-line binaries for Apple Silicon. It shows how to create a universal macOS binary containing both arm64 and x86_64 slices using the hidden --arch flag, and how to build separately for each architecture and combine the results with lipo, including an approach that also works on Linux. ### Source excerpt If you distribute binaries for command line tools built with Swift Package Manager, you might have previously built your distribution binary with: % swift build --configuration release If you inspect the binary, you can see it was built for the current machine's architecture by default: % file .build/release/package .build/release/package: Mach-O 64-bit executable x86_64 Previously, this was sufficient since macOS only supported one architecture. Now, in order to fully utilize the native performance of Apple Silicon chips, we need to produce a fat binary that contains a slice for both x86_64 and arm64. Swift Package Manager has a few different ways to achieve this. The easiest way, as far as I can tell, is to pass the hidden --arch flag once for each architecture: % swift build --configuration release --arch arm64 --arch x86_64 This goes through a different code path in Swift Package Manager, and utilizes Xcode's underlying XCBuild tool. This results in the built binary being in a different path than usual. Inspecting the new artifact, we can see we have a binary containing both requested architectures: % file .build/apple/Products/Release/package .build/apple/Products/Release/package: Mach-O universal binary with 2 architectures: [x86_64:Mach-O 64-bit executable x86_64] [arm64:Mach-O 64-bit executable arm64] .build/apple/Products/Release/package (for architecture x86_64): Mach-O 64-bit executable x86_64 .build/apple/Products/Release/package (for architecture arm64): Mach-O 64-bit executable arm64 Another option is to build once for each architecture, and then combine the binaries using lipo. Unlike the --arch option, this approach also works on Linux. Here's an example: % swift build --configuration release --triple arm64-apple-macosx % swift build --configuration release --triple x86_64-apple-macosx % lipo -create -output package .build/arm64-apple-macosx/release/package .build/x86_64-apple-macosx/release/package Inspecting our final binary we can see it correctly ## December 2019 round-up DevFeed: [December 2019 round-up]() Original publisher: [Read original article]() Author: Samuel Dionne-Riel Published: 2020-01-08T00:00:00Z Content type: news Language: en Sources: [Mobile NixOS news]() Topics: [Mobile](), [qemu](), [xfce](), [adb](), [boot](), [pixel](), [color](), [x86]() Tags: [adb](), [boot](), [color](), [mobile](), [pixel](), [qemu](), [x86-64](), [xfce]() ### AI overview This December 2019 Mobile NixOS project update summarizes merged changes, including a more touch-accessible example system, QEMU fixes with portrait-mode VGA BIOS support, stage-1 boot and failure-state improvements, adb fixes, Google Pixel 2 framebuffer fixes, and support for the Xiaomi Redmi Note 7. ### Source excerpt This update is the second in a series of regular updates on the state of the project. Only changes that have been accepted and merged in Mobile NixOS are chronicled here. There's always more work currently in-progress. Notable changes Among the changes, and the 10 PRs merged, these changes are highlighted. Make the demo more useful on a touch device These are changes to the "example" system. This is a finalized version of the demo system that was running on the devices during NixCon 2019. The main difference is that this is not a raw XFCE desktop, but a pre-configured system that is more accessible on touch devices. The onboard on-screen keyboard is configured to be of a useful height. Additionally, XFWM has been replaced with Awesome WM configured to maximize all windows. This is still not an appropriate mobile environment, only a collection of configuration that makes it work well enough to test things up. Read more in pull request #63. Enhance QEMU Device The x86_64 based QEMU VM has seen fixes to, first, make it actually work right. What's more interesting in this PR is the patched VGA BIOS that rotates the expected resolutions (720p, 1080p) on their side in portrait mode. This is especially helpful when working on purely software things like improving the example system. These changes are part of pull request #59. Different stage-1 fixes The root filesystem is configured to expand to the size of its backing partition during boot. Part of pull request #61. Critical failure states are graphically reported. As documented, a full-screen color-coded "sad phone" gives a general idea of the error encountered. Part of pull request #58. Other notable changes #41 fixing adb for stage-2. #67 which fixes spurious framebuffer failures on Google Pixel 2. Ports One new device has been merged during December. Xiaomi Redmi Note 7 (xiaomi-lavender) [@samueldr] (#28) Bringing the total of devices to 10. ## Type Punning Functions in C DevFeed: [Type Punning Functions in C]() Original publisher: [Read original article]() Author: Evan Miller Published: 2016-08-10T15:20:00Z Content type: article Language: en Sources: [Evan Miller]() Topics: [C](), [functions](), [x86](), [Assembly](), [cpu]() Tags: [assembly](), [c](), [cpu](), [functions](), [standard](), [unix](), [windows](), [x86-64]() ### AI overview This article demonstrates how C function pointers can be used with incompatible argument orders, producing type-punning behavior that depends on x86 calling conventions rather than the C standard. It explains how register-based argument passing contributes to the observed results and warns that the technique is architecture-dependent and unsafe. ### Source excerpt Making C more flexible, with the help of x86_64 calling conventions: Type Punning Functions in C ## Learning assembler on Linux DevFeed: [Learning assembler on Linux]() Original publisher: [Read original article]() Author: Graham King Published: 2014-08-23T03:49:14Z Content type: tutorial Language: en Sources: [Graham King]() Topics: [Assembly](), [Linux](), [Programming](), [x86](), [Code]() Tags: [assembler](), [assembly](), [linker](), [linux](), [linux-kernel](), [programming](), [software](), [x86](), [x86-64]() ### AI overview A programmer documents learning assembly on Linux, comparing AT&T and Intel syntax, assemblers, and 32-bit versus 64-bit targets. The article also explains entry points, linker behavior, system calls, and explicit program termination. ### Source excerpt "Diving into the nitty-gritty of assembly: A programmer's adventure!" [Next page]()