diff --git a/content/about.md b/content/about.md
index b72b490..7336623 100644
--- a/content/about.md
+++ b/content/about.md
@@ -36,7 +36,7 @@ All Apple Silicon Macs are in scope, as well as future generations as developmen
Asahi Linux is an overall project to develop support for these Macs. The majority of the work resides in hardware support, drivers, and tools, and it will be upstreamed to the relevant projects. Our flagship distro is [Fedora Asahi Remix](/fedora), which is a collaboration between Asahi Linux and the Fedora Project, and serves as both a polished end-user distribution and a reference for other distributions who wish to incorporate our work.
-Other distributions are already working on implementing support for these platforms, and we expect to have more options officially available in the future. Check out our [Alternative Distros](/docs/alt/alt-distros) page for a list of ongoing distro integration projects.
+Other distributions are already working on implementing support for these platforms, and we expect to have more options officially available in the future.
## Does Apple allow this? Don't you need a jailbreak?
diff --git a/content/blog/2025/05/15-progress-report-6-15.md b/content/blog/2025/05/15-progress-report-6-15.md
new file mode 100644
index 0000000..524e406
--- /dev/null
+++ b/content/blog/2025/05/15-progress-report-6-15.md
@@ -0,0 +1,166 @@
++++
+date = "2025-05-15T13:00:00+10:00"
+draft = false
+title = "Progress Report: Linux 6.15"
+slug = "progress-report-6-15"
+author = "James Calligeros"
++++
+
+Linux 6.15 is right around the corner, which means it's time for another progress
+report! We have been pretty busy behind the scenes and we have some exciting developments
+to share with you all.
+
+## Fedora Asahi Remix 42 Release
+Last time, we announced that Fedora Asahi Remix 42 was close to release. It has since
+[released](https://fedoramagazine.org/fedora-asahi-remix-42-is-now-available/) and is
+now available to install! The Asahi Installer now offers Fedora Asahi Remix
+42 images by default, and existing users on FAR 40 and 41 are encouraged to upgrade using
+[`dnf system-upgrade`](https://docs.fedoraproject.org/en-US/quick-docs/upgrading-fedora-offline/)
+or Plasma's Discover to start enjoying the latest versions of your favourite
+software. This is also a reminder that Fedora Asahi Remix follows the [Fedora Linux lifecycle policy](https://docs.fedoraproject.org/en-US/releases/lifecycle/),
+and thus Fedora Asahi Remix 40 is now fully end-of-life (EOL).
+
+## Fewer forks, more spoons
+We are pleased to announce that our graphics driver userspace API (uAPI) has been merged
+into the Linux kernel. This major milestone allows us to finally enable OpenGL, OpenCL and Vulkan
+support for Apple Silicon in upstream Mesa. This is the only time a graphics driver's
+uAPI has been merged into the kernel independent of the driver itself, which was kindly
+allowed by the kernel graphics subsystem (DRM) maintainers to facilitate upstream Mesa enablement while
+the required Rust abstractions make their way upstream. We are grateful for this one-off exception,
+made possible with close collaboration with the kernel community.
+
+This means that we will soon sunset our Mesa, virglrenderer, and Flatpak runtime forks. Eliminating these forks lightens
+our maintenance burden, and working directly with upstream Mesa improves the development
+experience for folks working on the userspace graphics stack. It also means that other distros
+like [Debian](https://salsa.debian.org/xorg-team/lib/mesa/-/commit/bcd9afe05d2e31459eb8c1f54b6dda2a257cbf14)
+and [Gentoo](https://github.com/gentoo/gentoo/commit/23e382acf4f7d75e49bc694f409c92385283632f), and
+the [Freedesktop SDK](https://gitlab.com/freedesktop-sdk/freedesktop-sdk/-/commit/13e0add938f4c74887a08ad0ef6493502a8d3913)
+can provide userspace graphics support for Apple Silicon without any additional packaging burden.
+
+Fedora Asahi Remix will drop the forked packages with the upcoming Fedora Linux 43
+based release. We expect that to happen without user intervention. The transition will be
+disruptive for Fedora Rawhide, but Rawhide is not supported or expected to be used on end-user systems.
+
+Upstreaming the uAPI has been an ongoing effort behind the scenes for
+a long time. Making a single change to the uAPI requires commensurate changes to the
+kernel driver, Mesa and virglrenderer. These changes need to be synchronised, since Mesa
+and virglrenderer rely on the uAPI to communicate with the kernel driver. Some keen observers
+may have noticed that [many](https://lore.kernel.org/asahi/20250310-agx-uapi-v1-1-86c80905004e@rosenzweig.io/) [versions](https://lore.kernel.org/asahi/20250313-agx-uapi-v2-1-59cc53a59ea3@rosenzweig.io/) [of](https://lore.kernel.org/asahi/Z-Fn4niI6_Yd06Ze@blossom/) [the](https://lore.kernel.org/asahi/20250323-agx-uapi-v4-1-12ed2db96737@rosenzweig.io/) [uAPI](https://lore.kernel.org/asahi/20250326-agx-uapi-v5-1-04fccfc9e631@rosenzweig.io/) [were](https://lore.kernel.org/asahi/20250327-agx-uapi-v6-1-df6b878a61b2@rosenzweig.io/) [submitted](https://lore.kernel.org/asahi/20250408-agx-uapi-v7-1-ad122d4f7324@rosenzweig.io/) to the kernel mailing lists
+before it was finally merged. Some of the changes between versions were fundamental
+in nature, requiring significant rework to the userspace components and
+kernel driver itself. Alyssa and Janne dedicated countless hours to this endeavour over
+the past few months - making changes, testing them, changing the changes, testing the
+new changes, rinse and repeat. As ever, they have our deepest gratitude and respect
+for pouring so much of their time and effort into closing this out.
+
+## Even more kernel upstreaming!
+The past couple of months have also led to even more kernel patches finding their
+way upstream. Linux 6.15 sees the introduction of the Apple Display Pipe (ADP) display
+controller and Z2 touchscreen digitizer drivers, which together enable Touchbar
+support in the upstream kernel for the M1 and M2 13" MacBook Pros.
+
+Also finding their way upstream are a number of critical patches for supporting various
+functional blocks in Apple's SoCs. PCIe controller support has been merged for the
+T6020 SoC (M2 Pro), which lays the groundwork for supporting the USB-A ports on
+the M2 Pro Mac mini, as well as WiFi and Bluetooth on all M2 Pro devices. WiFi/BT
+additionally depends upon the System Management Controller. Work is ongoing to get
+the SMC driver upstreamed.
+
+Linux 6.15 also includes some patches we require for audio, particularly around the TAS2764 and TAS2770 speaker amp chips.
+These patches add basic support for the Apple-specific variants found in Apple Silicon
+Macs.
+
+## I can't triforce
+Last update, we released microphone support for most laptops. We have since added
+support for the M1 and M2 13" MacBook Pros. Unfortunately, wider release of the microphone
+stack revealed a number of issues. We discovered that the Always-On Processor (AOP) on M2 Pro/Max devices
+differs slightly from the rest of the Apple Silicon family, meaning that microphones
+currently do not work on laptops with those SoCs. Work is underway to sort this out,
+so hang tight!
+
+As discussed last time, Triforce is my naive attempt at implementing a beamformer with
+minor prior knowledge. In my haste to get something working out the door in a
+reasonable timeframe, I made some questionable, _temporary_ engineering decisions.
+Surely I would have time to undo these soon, right?
+
+There is nothing more permanent than a temporary solution. Life got in the way, and I
+found myself with no time to rectify the issues. Ah well, performance is pretty
+bad, but it works well enough...
+
+One of the assumptions I made when building Triforce is that PipeWire's "quantum" (buffer
+size) will always be 1024 samples. At the time, I thought this would be true on every Apple Silicon Mac. Turns out that was a
+bad assumption. If Triforce sees an input buffer that is smaller than 1024 samples,
+it will return nothing to the graph, effectively muting the microphone.
+
+[Frédéric Bour](https://github.com/let-def) ran into this somehow on Fedora Linux 42, and in
+the process of fixing it also took it upon himself to fix many of the other bad choices
+I made in the course of development. The end result is that Triforce should now be more
+accommodating of oddball PipeWire configurations, and about 4 times faster! A huge
+thanks to Frédéric for picking up my slack on this one.
+
+## Upcoming talks
+May brings with it [Red Hat Summit](https://www.redhat.com/en/summit) and
+June brings [DevConf CZ](https://devconf.info/cz). Asahi will be present at both.
+At RH Summit, Neal and Davide will [present](https://events.experiences.redhat.com/widget/redhat/sum25/SessionCatalog2025/session/1731519631980001Xort)
+Fedora Asahi Remix and CentOS Hyperscale Asahi Remix as accessible platforms
+for developers targeting Linux on ARM64. The [talk](https://pretalx.devconf.info/devconf-cz-2025/talk/P3TEBA/)
+at DevConf CZ will focus on the effort to port CentOS Stream to Apple Silicon.
+Both sessions will be available online.
+
+## We're chronically online
+In addition to our [Mastodon](https://social.treehouse.systems/@AsahiLinux) profile, we now
+have Bluesky and LinkedIn accounts. You can follow us at [@asahilinux.org](https://bsky.app/profile/asahilinux.org)
+on Bluesky, and at [Asahi Linux](https://www.linkedin.com/company/asahilinux/)
+on LinkedIn.
+
+## New distro guidelines
+Since the beginning of the project, folks from all walks have worked to support Apple
+Silicon in their favourite distros. This immense interest is a gratifying confirmation
+that the community values our work.
+
+As part of our effort to encourage distros to take up Apple Silicon support, we have
+accommodated all third-party efforts, even allowing distro-specific
+documentation on our project's website. Unfortunately, this has led to
+an impression that we, as the upstream Asahi Linux developers, are involved
+with or otherwise endorse these efforts. This creates both an expectation
+of support and an impression that these efforts are representative of the state
+of Apple Silicon support, or even the state of the broader AArch64 ecosystem. These expectations are
+a significant and growing burden on us, and we need to address it.
+
+We have released [guidelines](https://asahilinux.org/docs/alt/policy/)
+outlining our expectations for distros supporting Apple Silicon. These
+guidelines target official distro projects wishing to collaborate directly with us. We will
+never discourage anyone from adding Apple Silicon support to any distro they choose, but we
+cannot offer official support or endorsement to those projects either.
+
+As a result, we are purging all distro-specific documentation and filtering
+the list of advertised distros to only those which follow the guidelines.
+
+Our long-term goal remains upstreaming everything such that Apple Silicon does not need
+any special treatment or handling.
+
+## Infrastructure ownership
+Until recently, most of our infrastructure was under the control of individuals, including
+domain names. Over the past month, we have been working on transferring as much of this
+as possible away from developers' private accounts and into ownership at the project level.
+This ensures that the project is resilient against any one person leaving.
+It also makes it easier for project expenses to be accounted for. For example, having
+our domain names under the financial ownership of Open Source Collective means that all
+domain-related expenses are processed automatically, rather than needing to paid out
+by a developer and reimbursed.
+
+## Coming up next...
+We have a few items currently pending review on the mailing list, or merged pending
+release in Linux 6.16. Of particlar note are drivers for the SMC and SPMI controller.
+The SMC is important for system shutdown and reboot, GPIO (required to e.g. power on the WiFi board),
+various hardware monitoring sensors, and the RTC. SPMI is a two-wire serial bus similar to I2C.
+Important peripherals, like the power management controller, are attached via this bus.
+Starting with the M3, the USB PD controllers, which negotiate the mode
+(e.g. USB3, Display Port, etc.) with the devices attached to the ports and forward
+it to the PHY and USB controller, are also attached to SPMI rather than
+I2C, making the SPMI controller driver essential for supporting
+those devices. We hope to have more to share in the next progress report.
+
+As always, we want to thank everyone who supports us on [OpenCollective](https://opencollective.com/asahilinux/)
+and [GitHub Sponsors](https://github.com/sponsors/AsahiLinux). None of this would be possible
+without your generous support.
diff --git a/content/blog/2025/08/07-progress-report-6-16.md b/content/blog/2025/08/07-progress-report-6-16.md
new file mode 100644
index 0000000..b12d9a3
--- /dev/null
+++ b/content/blog/2025/08/07-progress-report-6-16.md
@@ -0,0 +1,231 @@
++++
+date = "2025-08-07T22:00:00+10:00"
+draft = false
+title = "Progress Report: Linux 6.16"
+slug = "progress-report-6-16"
+author = "James Calligeros"
++++
+
+With Linux 6.16 now out in the wild, it's time for yet another progress report!
+As we mentioned last time, the Asahi and Honeykrisp Mesa drivers have finally
+found their way upstream. This has resulted in a flurry of GPU-related work, so
+let's start there.
+
+## No missing nuts in this Flatpak
+For quite some time, we have maintained a version of our Mesa driver built against
+the Flatpak runtime and shipped it as a Flatpak runtime extension. This was required
+to enable GPU acceleration on Flatpak while our Mesa driver was not enabled upstream.
+As Flatpak runtime version 23.08 reaches end of life this month, this will no longer
+be necessary. 24.08 now ships with Mesa 25.1, and so will the forthcoming 25.08
+runtime. Once 25.08 is released, we will be discontinuing the Flatpak runtime
+extension as it will serve no purpose.
+
+## A _fully_ upstream graphics stack
+Asahi uses DRM Native Context to paravirtualise the GPU. Rather than having to
+virtualise high-level APIs like DirectX and Vulkan, the VM runs the userspace component
+of the host's native GPU driver. The host is then passed native GPU commands that it
+only needs to forward on to the kernel without modifying. This improves GPU
+performance inside muvm, our virtual machine for [gaming on Asahi Linux](https://asahilinux.org/2024/10/aaa-gaming-on-asahi-linux/).
+Until now however, this has relied on downstream patches to virglrenderer and Mesa.
+
+We are pleased to announce that our DRM Native Context implementation has now
+been merged into the upstream virglrenderer project, and will therefore be enabled
+in upstream Mesa 25.2! This completes our transition to a fully upstream graphics
+stack, and as such we are retiring our Mesa fork completely.
+
+## GPU go brrrrr
+Now that our Mesa driver is totally upstream, work on improving it has been able to
+occur rapidly. Alyssa has been hard at work over the past couple of months optimising
+performance. [A whole mess of merge requests](https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/?sort=created_date&state=merged&label_name%5B%5D=asahi&author_username=alyssa)
+have found their way upstream, with the bulk of them being merged in time for the
+release of Mesa 25.2. Performance improvements are variable but decent, especially
+when paired with [this month's improvements](https://fex-emu.com/FEX-2508/) to FEX's JIT.
+
+## A fine vintage
+Also new in Mesa 25.2 is support for `VK_EXT_map_memory_placed`, courtesy of
+chaos_princess. This Vulkan extension allows applications to request GPU memory
+be mapped at a specific address. WINE uses this when thunking 32-bit DXVK to
+ensure any memory allocated by the GPU driver is within a 32-bit address space.
+This is required to enable GPU acceleration for 32-bit Windows applications.
+What's that? Your 32-bit games already work in FEX? Well...
+
+The stack we currently ship to enable gaming is quite a beast. At the bottom
+we have muvm, which spins up a micro VM (who would've guessed) using a kernel
+configured with 4K memory pages. FEX as it ships today requires this; the x86
+architecture only supports 4K pages and we cannot "split" a memory page into
+smaller pages, only combine them to create pages of a larger size. Atop that
+is FEX, which translates x86 binaries so they can run on 64-bit ARM devices.
+But binary applications are very rarely self-contained monoliths. They require
+access to kernel functions via syscalls, system libraries like glibc, and
+access to the GPU via APIs like Vulkan.
+
+The obvious solution---and the one used by FEX---is to translate the entire
+world. When FEX loads an x86 or amd64 application, its loader pulls whichever
+libraries the application binary is linked to from a disk image or mount point
+containing a multilib amd64 root filesystem, and translates them. The benefit
+here is that the application we want to run gets ABI-correct, native versions of
+any libraries it's linked against. The disadvantages, however, are significant.
+
+The image needs to have whichever libraries any arbitrary application could
+realistically be linked to. We either accept that some applications simply will
+not run, or we ship everyone an enormous filesystem image full of libraries for
+a foreign machine that they will likely never use. There are also the runtime
+costs associated with translating a bunch of libraries and faking syscall
+interfaces for their benefit. We can do better than this.
+
+The emulation stack is being used overwhelmingly for gaming via WINE/Proton.
+For the sake of simplicity, let us simplify the problem space and say that our
+goal is not to run x86 Linux applications, but x86 Windows applications, and
+games especially.
+
+Users of Windows on Arm will have noticed that it can run x86 applications.
+I'll spare you the Windows NT history lesson for today, but the NT team's almost
+religious focus on abstraction, portability and backward compatibility for nearly
+40 years has given us three _very_ important and beneficial features:
+
+- WoW64, which thunks out 32-bit system calls to their 64-bit counterparts
+- An API to plug binary translators into WoW64
+- 64K virtual memory pages, regardless of the underlying physical page size
+
+Since WINE implements WoW64 and FEX implements the WoW64 binary translator API,
+AArch64 WINE is capable of running 32-bit x86 applications. Since all Windows
+applications are allocated 64K pages, we _theoretically_ (more on this in a bit)
+don't need to worry about page size. With `VK_EXT_map_memory_placed`, all of the
+pieces of the puzzle are now in place; AArch64 WINE can now run 32-bit Windows
+applications and games _without_ muvm!
+
+- We no longer have to paravirtualise the GPU, network access, or filesystem
+- We no longer have to mangle and proxy the X11 or PipeWire protocols
+- WINE can now use Wayland directly rather than be forced through XWayland
+- FEX only has to translate x86 Windows code; WINE calls out to native AArch64 64-bit Windows
+ and \*nix
+
+That said, your mileage may vary...
+
+While it's true that Windows allocates 64K virtual memory pages, not all applications
+respect this. Windows application developers have a long tradition of simply
+ignoring the Windows API, with game developers committing particularly heinous crimes
+in pursuit of performance. This often means baking x86-isms like 4K physical memory
+pages into code. Any applications which do this simply will not work, and will continue
+to require the use of muvm. You will however be able to use WoW64 inside muvm, and these
+applications will still reap most of the benefits from doing so.
+
+You should also expect bugs in FEX and WINE, though unlike broken Windows
+applications from 2003, these have a pretty good chance of being fixed.
+
+Want to try this out for yourself? Some distros already make this seamless; thanks
+to chaos_princess once again, Gentoo automatically installs FEX's WoW64
+implementation on AArch64 systems when the `wow64` USE flag is enabled. Simply
+install your preferred WINE flavour with the `wow64` USE flag and create a new
+WINE prefix to get started!
+
+On other distros, you will need to do some extra work:
+1. Ensure your distro builds AArch64 WINE with WoW64 enabled. This is not currently
+ the case for Fedora, but is coming soon!
+2. Install WINE using your native distro packages
+3. Download the latest `fex-emu-wine` build from the [FEX Ubuntu PPA](https://launchpad.net/~fex-emu/+archive/ubuntu/fex/+packages)
+4. Extract `libwow64fex.dll` _only_ to`/usr/lib/wine/aarch64-windows/xtajit.dll`
+5. Create a new WINE prefix
+
+Once you have a WINE prefix all set up, you can start enjoying your x86 Windows
+applications in a much improved fashion!
+
+
+
+
+
+
+ LEGO Star Wars (2005) running in native AArch64 WINE using DXVK
+
+
+
+
+What about amd64/x86_64/x64 applications, you ask? Well unfortunately there are some challenges
+unique to making amd64 Windows code run on an AArch64 Windows environment which mean we don't support this style of emulation for amd64 Windows applications.
+
+
+
+
+
+
+ AMD64 Notepad++ running in WINE's ARM64EC mode
+
+
+
+_...Yet._
+
+## We're getting there...
+As always, we have been hard at work upstreaming various bits and pieces.
+
+Devicetree bindings for the GPU have been accepted and merged for 6.17, which allows
+us to stabilise how m1n1 initialises the GPU and forwards information onward to
+the kernel.
+
+The SPMI controller driver, required for power management, landed in 6.16. The
+USB-C mux chips used in M3 Macs and above are also connected via SPMI bus, making
+this driver necessary for USB on those machines.
+
+A bunch of audio-related patches have landed in 6.16 and are queued for 6.17. Some
+of these patches rework the upstream I2S controller driver, allowing
+the speaker amps to feed speakersafetyd the data it needs. This brings us very
+close to being able to upstream everything required to support speakers upstream.
+
+The core SMC driver has been accepted for 6.17, along with subdevice drivers for
+its GPIO controller and reset controller functions. Combined, these allow the
+upstream kernel to not only shut down and reboot Apple Silicon Macs, but also
+enable the WiFi/Bluetooth module and USB Type A ports on machines with them. Also
+in the pipeline for upstreaming is the hwmon driver to enable fan control and access
+to the myriad hardware sensors present on these machines, the SMC HID driver to support
+power button presses for suspend/resume, and the SMC RTC driver to read and update
+the current system time.
+
+With Linux 6.16, we also hit a pretty cool milestone. In our first progress report,
+we mentioned that we were carrying over 1200 patches downstream. After doing a little
+housekeeping on our branch and upstreaming what we have so far, that number is
+now below 1000 for the first time in many years, meaning we have managed to upstream
+a little over 20% of our entire patch set in just under five months. If we discount
+the DCP and GPU/Rust patches from both figures, that proportion jumps to just under half!
+
+While we still have quite a way to go, this progress has already made rebases
+significantly less hassle and given us some room to breathe.
+
+## Miscellaneous fixes
+Now that we have some time to do so, we have managed to progress a number of
+things that had been sitting on the backburner.
+
+Plymouth, the system used to display a boot splash screen instead of TTY messages,
+broke its automatic DPI scaling on 13-inch laptops at some point recently. We have
+now been able to fix this.
+
+A recent update to OBS broke screencasting on KMSRO systems implementing DRM
+explicit sync. This was found to be caused by compositor bugs, and has been fixed
+in [kwin](https://invent.kde.org/plasma/kwin/-/merge_requests/7941), and a merge
+request has been raised for [Mutter](https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/4547).
+As those fixes are not yet released and other compositors might have the same issue,
+Janne added DRM syncobj support to the DCP driver in [asahi-6.15.8-1](https://github.com/AsahiLinux/linux/releases/tag/asahi-6.15.8-1)
+as a workaround.
+
+Development on m1n1 has also started picking up again. The release of
+[1.5.0](https://github.com/AsahiLinux/m1n1/releases/tag/v1.5.0) marks the first new
+release since February. A number of small fixes were able to be merged, including
+a fix for boot time crashes caused by missing calibration data on Macs that have had
+their WiFi/Bluetooth module replaced. We also made it easier for distros to
+add a custom logo to m1n1.
+
+## Conference talks
+Davide and Neal presented at [Red Hat Summit](https://events.experiences.redhat.com/widget/redhat/sum25/SessionCatalog2025/session/1731519631980001Xort)
+and [DevConf.CZ](https://pretalx.devconf.info/devconf-cz-2025/talk/P3TEBA/),
+covering the ongoing work on Fedora Asahi Remix and introducing a CentOS Stream port
+as part of their work in the CentOS Hyperscale SIG. This was also covered
+at [CentOS Showcase](https://cfp.fedoraproject.org/centos-showcase-2025-07/talk/RRT8NW/) in July.
+
+## Project merch
+Want to show your love for Asahi Linux to the world? Now you can! Head over to
+[HELLOTUX](https://www.hellotux.com/asahi) to buy official Asahi Linux merch. A portion
+of each sale is donated to the project. Many thanks to HELLOTUX for facilitating this!
+
+## Until next time!
+Our next report should hopefully bring even more improvements and developments,
+so make sure to stick around. As always, a warm thanks goes out to our supporters
+on [OpenCollective](https://opencollective.com/AsahiLinux) and [GitHub Sponsors](https://github.com/sponsors/AsahiLinux),
+without whom this would not be possible.
diff --git a/content/blog/2025/10/24-progress-report-6-17.md b/content/blog/2025/10/24-progress-report-6-17.md
new file mode 100644
index 0000000..42d7b0f
--- /dev/null
+++ b/content/blog/2025/10/24-progress-report-6-17.md
@@ -0,0 +1,265 @@
++++
+date = "2025-10-24T10:30:00+10:00"
+draft = false
+title = "Progress Report: Linux 6.17"
+slug = "progress-report-6-17"
+author = "James Calligeros"
++++
+
+Another upstream kernel release means it must be time for a progress report!
+
+## The patches keep coming
+As always, upstreaming continues. The highlight of this cycle is finally landing
+the SMC core driver, after discussions on the mailing list going all the way back
+to 2022! Along with the core driver, drivers for the SMC's GPIO controller and
+reboot controller have also been merged. This allows devices which are already
+upstream to reboot gracefully, and lays the groundwork for enabling WiFi and
+Bluetooth upstream.
+
+Also merged for 6.17 are a few Devicetree changes which lay the groundwork for
+upstreaming GPU support. While these are ultimately a small piece of the whole GPU
+puzzle, they are very important. The Devicetree schema determines how the GPU kernel
+driver gets the information it needs from firmware to properly control the GPU. Now
+that this is stable and the properties merged into the upstream Devicetrees, we
+can be reasonably confident that the parts of the GPU driver that interact with
+the Devicetree won't require substantial changes.
+
+Work is also progressing on getting more SMC functionality upstream. The hardware
+monitoring, lid switch and power button, and RTC drivers are all close to being
+merged, with just a few minor issues left to address.
+
+Apple Silicon SoCs place peripheral devices and IP blocks (like the display
+controller) behind an IOMMU called DART. These act as a sort of firewall for peripherals,
+preventing them from accessing memory addresses that they shouldn't. The DARTs on the
+M2 Pro, Max and Ultra (T602x) SoCs are *mostly* compatible with those found on
+the base M2, with one caveat: they support a larger address space. Supporting this
+required implementing four-level pagetables in the DART driver. This change, along
+with the Devicetrees for all M2 Pro, Max and Ultra based devices have now been merged,
+and are available in v6.18-rc1!
+
+And of course, there are the USB patches. It seems like just about everyone's
+been following these on the mailing list, so it would be remiss not to mention
+them. Anyway, moving on.
+
+## m1n1's starting to Rust
+Slowing down the kernel treadmill has enabled us to finally start taking a look
+at other parts of the stack, and we've been making some important (and long
+overdue) changes to m1n1.
+
+For a while now, the recommended method for installing non-Fedora distros has
+been to use the "UEFI Only" installer option, then boot the preferred distro's
+Asahi installation media from USB. However, it has been quite some time since
+this installation option was updated, and the m1n1/U-Boot/Devicetree bundle it was
+installing was over two years old. A lot has changed in that time, and it turned
+out that this bundle was not capable of booting modern Asahi kernels. Oops.
+
+To fix this, Janne has added a [CI pipeline](https://github.com/AsahiLinux/m1n1/actions/workflows/installer.yml)
+to the m1n1 repo that will automatically build the UEFI bundle for us. With
+this step automated, it is now trivial to upload the resulting artefact to our CDN
+and point the Asahi Installer to it. The update cadence should now be a lot more
+frequent than biennially!
+
+We have also released [m1n1 v1.5.2](https://github.com/AsahiLinux/m1n1/releases/tag/v1.5.2).
+This release is fairly uncontroversial, with the main changes being adding
+compatibility for the now-upstream USB and GPU Devicetree schema. However, this will
+likely be our last m1n1 release that can be built without Rust.
+
+We believe that it is important for such a critical piece of software to be as
+maintainable, safe and logically sound as possible, especially given that it is
+*supposed* to root the chain of trust in a hypothetical Secure Boot environment.
+Certain components of m1n1 being written in C means that we currently cannot meet
+any of those goals.
+
+One such component was the Apple Device Tree handling code. While the ADT is
+implicitly trustworthy data, the original C implementation was quite haphazardly
+put together. This resulted in an unsound API based on libfdt that was neither
+ergonomic to use nor a particularly good fit for the ADT data itself.
+
+I was able to develop a sound, idiomatic Rust implementation and API with a little
+help from our resident Rust expert chaos_princess, and bind that back to the existing
+C API so that all our existing C code can make use of it. After a round of bug-squashing,
+we found that there is no speed difference between the old and new implementations,
+even with the overhead of the FFI glue logic!
+
+We don't have any plans to actively port *all* of m1n1 to Rust. Safety-critical
+components in the boot chain are our primary focus, followed closely by components
+which could directly benefit from a rewrite due to unsound or unergonomic C APIs.
+Perhaps one day we will have an all-Rust m1n1, but if it happens it will do so
+organically over time.
+
+## WoW!
+Last time, we teased working 64-bit Windows applications running in WINE outside of
+muvm. Granted, Notepad++ is not a particularly exciting teaser, but we believe it is
+important to be transparent and set realisitic expectations. Anyway, here are both
+Hollow Knight and NieR:Automata---64-bit Windows games---running on WINE outside of muvm.
+
+
+
+
+
+
+ Hollow Knight (2017) running outside of muvm on an M1 Pro MacBook Pro with Gentoo
+
+
+
+
+
+
+
+
+
+ NieR:Automata (2017) running outside of muvm on an M1 Pro MacBook Pro with Gentoo
+
+
+
+Thanks once again to chaos_princess, the toolchain changes we were waiting for last
+time have now been integrated into Gentoo, and the required FEX DLLs are built
+automatically when installing WINE.
+
+Mileage will vary to an even greater degree than 32-bit applications, however.
+WINE's support for ARM64X and ARM64EC (Microsoft's ABI and executable format
+that allow AArch64 and amd64 code to interoperate) is still incomplete, so
+many applications simply will not work (yet). We of course encourage folks who
+like to live dangerously to give it a try, but we cannot provide any support
+for this stack. Consider it an early alpha, a glimpse at better things to come.
+
+## Helping developers
+When we first started the project, we created [macvdmtool](https://github.com/AsahiLinux/macvdmtool)
+to puppeteer a device under test using Apple's USB-PD Vendor Defined Messages.
+These allow the user to reboot a Mac over USB and to route the SoC's primary
+UART to the USB port. These features are very useful when doing early device
+bringup. Rebooting the machine with this method works even when the system is
+locked up, and having access to the UART means that we can inspect any boot logs
+without relying on an initialised display or USB stack. macvdmtool relies on IOKit,
+a macOS system library. Having to use macOS for development is painful, but what
+if we could achieve the same functionality with a Linux utility instead?
+
+[tuxvdmtool](https://github.com/AsahiLinux/tuxvdmtool) is a reimplementation
+of macvdmtool on Linux, made possible by changes to the USB-C mux chip driver
+present in our downstream kernel. tuxvdmtool offers the same features as macvdmtool,
+with the added benefit of allowing the "host" system to be an Apple Silicon device
+running Linux! Having access to a familiar and fully-featured Linux development
+environment helps make early bringup work just that little bit more accessible.
+We hope that tuxvdmtool encourages more folks to experiment with low-level bringup
+on Apple Silicon devices.
+
+While the kernel patches required to make this work are not upstreamable, a future
+release of tuxvdmtool will be rewritten to use the Linux kernel's builtin
+[i2c dev interface](https://docs.kernel.org/i2c/dev-interface.html), which will
+allow us to drop them entirely.
+
+## Helping everyone
+We have always strived to work directly with upstream projects on Apple Silicon
+support where possible. This allows us to discuss ideas with those projects, get
+advice on the correct way to implement Apple Silicon support in their software, and
+in many cases even benefit the ecosystem more broadly. While this means we are
+beholden to the relevant upstream's release schedule, it also means that we don't
+have to worry about maintaining outdated forks, rebasing, backporting security
+patches, and any of the other software engineering things that are not directly
+related to supporting Apple Silicon devices. The past year has demonstrated
+clearly why not just an an upstream-first, but upstream-*only* approach to
+development is the only approach that makes sense long term.
+
+But working upstream is not only for our own benefit. Sometimes, the work we
+do can be of benefit to other users on other platforms. Well documented examples
+of this include getting projects to [work properly](https://asahilinux.org/docs/sw/broken-software/#fixed-packages)
+on machines with 16K pages, and the PipeWire and WirePlumber enhancements that
+allow us to automatically apply DSP profiles to each device. These were done with
+the direct benefit to others front and centre of mind.
+
+Sometimes, however, it can be those other users who find our work and put it to
+use of their own accord.
+
+Geometry shaders are a type of specialised shader which can work directly on
+polygons rather than vertices. Although now considered a legacy technique,
+some applications use them for various tasks, such as culling triangles from
+a scene based on some sort of filter condition.
+
+Similarly, tessellation is a graphical technique that allows GPUs to programmatically
+fill a surface with new polygons. This is used to implement adaptive LOD, highly
+detailed water, and increase the fidelity of models without having to ship
+large, high-poly assets.
+
+Modern high-performance GPUs support both of these with additional hardware,
+however this requires engineering effort as well as room in the design's power
+and die area budgets. Mobile GPU designers aim to minimise all three of these
+and more often than not end up emulating both geometry shaders and tessellation.
+Apple's GPUs, being derived from PowerVR and originally designed for iDevices,
+are no exception.
+
+While Vulkan does not mandate support for geometry shaders for this reason, OpenGL
+does from version 3.2 onwards, as does Direct3D 10 and up. Since we would very
+much like to support OpenGL as well as Direct3D translation, we need to be
+able to execute geometry shaders somehow.
+
+We may not have explicit support for geometry shaders, we *do* have support for
+compute shaders. With these, we can emulate full geometry shader and tessellation
+support on the GPU itself and avoid a great deal of the performance penalty
+associated with using the CPU.
+
+Of course this isn't as performant as full hardware acceleration, but it does
+at least allow us to advertise support for geometry and tessellation shaders to
+applications. This in turn allows us to claim conformance with all modern OpenGL
+versions, allows Vulkan applications to use geometry and tessellation shaders,
+*and* enables the translation of Direct3D for games running under WINE/Proton!
+
+Other mobile GPUs also have this problem. Arm's GPU designs for example do not
+have hardware support for geometry shaders or tessellation either.
+Enter [`poly`](https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37914),
+an effort by Mary Guillemard to convert our geometry and tessellation shader emulation
+into shared code that any Mesa driver can use. This can then be integrated into
+any Mesa GPU driver, enabling geometry and tessellation shader support without
+duplicating the emulation code itself!
+
+Be sure to keep an eye out for geometry shader, tessellation shader, and transform
+feedback support in Panfrost, the open source Arm GPU driver, as well as in KosmicKrisp,
+a conformant Vulkan 1.3 implementation for macOS layered on top of Metal.
+
+## Life, the Universe, and Everything. Plus one.
+Keen eyes may have noticed we've started building Fedora Asahi Remix
+[dailies](https://fedora-asahi-remix.org/builds.html) targeting Fedora Linux 43.
+The new upstream Fedora release is slated to come out later this month, and
+you can expect the Remix to follow shortly.
+
+## At the Akademy
+Neal and Janne attended [KDE Akademy](https://akademy.kde.org/) in Berlin this year.
+As the annual KDE community conference, this was an opportunity to ensure future work
+in KDE aligns well with Fedora Linux and Fedora Asahi Remix. Neal
+[gave a talk](https://youtu.be/CznIsJQQE9U?t=248) about the Fedora KDE Plasma Desktop
+Edition there, and prominently discussed Fedora Asahi Remix as part of it.
+
+Additionally, there was a lot of discussion about the upcoming Plasma Setup application,
+which will provide a better integrated experience for first boot of a Fedora KDE
+install. Lessons learnt from Fedora Asahi Remix user feedback is being directly
+incorporated into Plasma Setup, and Neal is working on integrating this for Fedora
+Linux 44 as [a formal Change](https://fedoraproject.org/wiki/Changes/Unified_KDE_OOBE).
+
+## M3? Kinda...
+Way back in the early days, we predicted that Apple would refrain from making
+sweeping architectural changes to the various functional blocks found in Apple Silicon
+SoCs unless absolutely necessary, and that this would enable the reuse of a
+lot of code and significantly cut down on the amount of reverse engineering required
+between generations. The example we gave was the interrupt controller, which is
+quite unfortunate because that was the first thing Apple ended up changing. Oops.
+
+But the overall principle has held mostly true. So much so in fact that some
+enterprising folks on Reddit have found that with only a trivial amount of
+hacking, you can actually boot Asahi on M3 series devices!
+
+It may be surprising to learn that very basic, low-level support for M3 has
+existed for quite some time now. m1n1 is capable of initialising the CPU cores,
+turning on some critical peripheral devices, and booting the Asahi kernel.
+However, the level of support right now begins and ends with being able to boot
+to a blinking cursor. Naturally, this level of support is not at all useful for
+anything but low-level reverse engineering, but we of course plan on rectifying
+this in due time...
+
+If you're interested in helping us out and have prior experience with reverse
+engineering or low-level embedded software development, we'd love for you to say
+hi on IRC or Matrix! See [this page](https://asahilinux.org/contribute) for more
+information.
+
+## Thanks!
+As always, a warm thanks to our sponsors on [OpenCollective](https://opencollective.com/asahilinux)
+and [GitHub Sponsors](https://github.com/sponsors/asahilinux), without whom we
+would not be able to keep the lights on. You're all truly wonderful!
diff --git a/content/code-of-conduct.md b/content/code-of-conduct.md
index b1fcdd8..aec54be 100644
--- a/content/code-of-conduct.md
+++ b/content/code-of-conduct.md
@@ -12,7 +12,7 @@ However, when a large and sufficiently diverse group of people work together, th
No list is ever exhaustive, so we encourage members of the Asahi Linux community to adhere to the spirit, rather than the letter, of this code, as that is how it will be enforced. Places where this code may be particularly applicable are GitHub issues and pull requests, IRC, Matrix, mailing lists, Fediverse discussions broadly directed at or between members of the community, and other direct interactions within the community. Any violations, especially continued or flagrant offenses, may affect an individual’s (or organization’s) ability to participate within the Asahi Linux community.
-If you feel that someone is in violation of the code of conduct, whether in letter or in spirit, we request that you email as detailed a description as possible of the offense and offending party/parties to [the board](mailto:alyssa@rosenzweig.io,davide@cavalca.name,neal@gompa.dev,jcalligeros99@gmail.com,j@jannau.net,fnkl.kernel@gmail.com,sven@svenpeter.dev). If you have questions, concerns, or any other inquiries please feel free to contact the board.
+If you feel that someone is in violation of the code of conduct, whether in letter or in spirit, we request that you email as detailed a description as possible of the offense and offending party/parties to [the board](mailto:coc@asahilinux.org). If you have questions, concerns, or any other inquiries please feel free to contact the board.
A large fraction of Asahi Linux consists of contributions to upstream projects. All Asahi Linux contributors are expected to adhere to the respective upstream Codes of Conduct when interacting with such projects, or developing code intended for upstreaming.
diff --git a/content/community.md b/content/community.md
index 2910893..78fbf70 100644
--- a/content/community.md
+++ b/content/community.md
@@ -35,6 +35,7 @@ The Fedora-specific Asahi discussions take place in Matrix on Fedora infra:
Our working documentation is maintained in a [documentation site](/docs) built from [GitHub](https://github.com/AsahiLinux/docs) using [MkDocs](https://mkdocs.org).
-## Mastodon (Fediverse)
+## Social media
-You will also find official announcements and information on the [Asahi Linux Mastodon account](https://social.treehouse.systems/@AsahiLinux).
+You will also find official announcements and information on the [Asahi Linux Mastodon (Fediverse) account](https://social.treehouse.systems/@AsahiLinux).
+These are also published to the [Asahi Linux Bluesky account](https://bsky.app/profile/asahilinux.org) and the [Asahi Linux LinkedIn page](https://linkedin.com/company/asahilinux/).
diff --git a/content/copyright.md b/content/copyright.md
index 5eed8ac..297238f 100644
--- a/content/copyright.md
+++ b/content/copyright.md
@@ -109,7 +109,7 @@ Similarly, if any firmware blobs are uploaded to the hardware, those cannot be c
Asahi Linux does not ban binary disassembly and decompilation as a means to obtain knowledge required to write open source implementations. However, this is a dangerous road. We have seen many cases of "open source" code that was developed by direct translation of reverse engineered binary code. This is unacceptable, and would put the entire project and upstream projects at risk.
-Since the Asahi Linux project board is ultimately responsible for certifying the origin of code upstreamed as part of the project, we need to ensure that any instances of this approach are following a process that does not result in copyright infringement. We have previously seen other projects take contributions that turned out not to be clean, putting those projects into legal doubt - this was often discovered long after the code was contributed, as the origin of the code may not be immediately apparent. For this reason, we do not currently allow contributions of code developed concurrently with binary reverse engineering except from specific trusted contributors. Please contact [the board](mailto:alyssa@rosenzweig.io,davide@cavalca.name,neal@gompa.dev,jcalligeros99@gmail.com,j@jannau.net,fnkl.kernel@gmail.com,sven@svenpeter.dev) for details.
+Since the Asahi Linux project board is ultimately responsible for certifying the origin of code upstreamed as part of the project, we need to ensure that any instances of this approach are following a process that does not result in copyright infringement. We have previously seen other projects take contributions that turned out not to be clean, putting those projects into legal doubt - this was often discovered long after the code was contributed, as the origin of the code may not be immediately apparent. For this reason, we do not currently allow contributions of code developed concurrently with binary reverse engineering except from specific trusted contributors. Please contact [the board](mailto:board@asahilinux.org) for details.
All other contributors are required to follow the textbook "clean-room" approach: If you would like to disassemble/decompile components in order to contribute to the project, you must make that decision for a specific component/area with care, and once you do, you are expected to only contribute to that area by writing clean documentation of the hardware, and let other project members implement it.
diff --git a/content/fedora.md b/content/fedora.md
index 721c9a1..99cb7e4 100644
--- a/content/fedora.md
+++ b/content/fedora.md
@@ -1,6 +1,6 @@
---
title: Fedora Asahi Remix
-date: "2024-12-17T12:45:00-04:00"
+date: "2025-04-15T11:27:00-04:00"
draft: false
body_class: "landing fedora"
layout: landing
@@ -21,11 +21,11 @@ layout: landing
-##
Fedora Linux 41 + Apple Silicon = Fedora Asahi Remix
+##
Fedora Linux 42 + Apple Silicon = Fedora Asahi Remix
-Fedora Asahi Remix is the result of a close multi-year collaboration between the Asahi Linux project and the [Fedora Project](https://fedoraproject.org/). We've worked hard in order to bring you a fully integrated distro, cooperating closely to get improvements and bug fixes to users as quickly as possible. All of our Asahi platform-specific packages are in upstream Fedora and fully supported in Fedora Linux 41.
+Fedora Asahi Remix is the result of a close multi-year collaboration between the Asahi Linux project and the [Fedora Project](https://fedoraproject.org/). We've worked hard in order to bring you a fully integrated distro, cooperating closely to get improvements and bug fixes to users as quickly as possible. All of our Asahi platform-specific packages are in upstream Fedora and fully supported in Fedora Linux 42.
-With Fedora's excellent 64-bit ARM support and mature development process, you can expect a solid and high-quality experience without any unwanted surprises. Fedora Asahi Remix is based on Fedora Linux 41, the latest Fedora Linux release with the newest software versions across the board. All M1 and M2 series MacBook, Mac Mini, Mac Studio, and iMac devices are supported.
+With Fedora's excellent 64-bit ARM support and mature development process, you can expect a solid and high-quality experience without any unwanted surprises. Fedora Asahi Remix is based on Fedora Linux 42, the latest Fedora Linux release with the newest software versions across the board. All M1 and M2 series MacBook, Mac Mini, Mac Studio, and iMac devices are supported.
@@ -36,9 +36,9 @@ With Fedora's excellent 64-bit ARM support and mature development process, you c
Want to use Night Color to keep your screen from disrupting your sleep cycle? No worries, it just works. Tweak your trackpad settings for a more comfortable experience? Everything's right there in System Settings. Are things on screen too big or too small? Just adjust the display scale to your heart's content, even in 5% increments. We've worked with the KDE project to bring you bug fixes and improvements to improve platform support, and we've also built a custom Calamares-based initial setup wizard so you can be up and running in no time with minimal fuss.
-Fedora Linux 41 comes with [KDE Plasma 6.2](https://kde.org/announcements/plasma/6/6.2.0/), with the latest patches and improvements to provide *the* premier desktop experience.
+Fedora Linux 42 comes with [KDE Plasma 6.3](https://kde.org/announcements/plasma/6/6.3.0/), with the latest patches and improvements to provide *the* premier desktop experience.
-Rather use [GNOME](https://www.gnome.org/)? No worries, we've got you covered with [GNOME 47](https://release.gnome.org/47/). Or, if you prefer to roll your own desktop configuration or want to set up a headless server, our Minimal and Server images will let you set things up exactly the way you want to.
+Rather use [GNOME](https://www.gnome.org/)? No worries, we've got you covered with [GNOME 48](https://release.gnome.org/48/). Or, if you prefer to roll your own desktop configuration or want to set up a headless server, our Minimal and Server images will let you set things up exactly the way you want to.
@@ -121,6 +121,7 @@ With our in-house [Bankstown](https://github.com/chadmed/bankstown) bass boost t
Trackpad
Headset Jack
Speakers
+
Microphone
Camera
MagSafe*
USB Type C (USB 3.0)
@@ -128,7 +129,6 @@ With our in-house [Bankstown](https://github.com/chadmed/bankstown) bass boost t
Bluetooth
USB-C Displays
Thunderbolt / USB4
-
Microphone
Touch ID
* Available on M2 model only.
@@ -151,6 +151,7 @@ With our in-house [Bankstown](https://github.com/chadmed/bankstown) bass boost t
Touch Bar†
Headset Jack
Speakers
+
Microphone
Camera
MagSafe‡
USB Type C (USB 3.0)
@@ -160,7 +161,6 @@ With our in-house [Bankstown](https://github.com/chadmed/bankstown) bass boost t
Bluetooth
USB-C Displays
Thunderbolt / USB4
-
Microphone
Touch ID
* Local dimming available on 14" and 16" models. Maximum 60Hz refresh rate on all models. HDR/120Hz not yet supported.
diff --git a/content/governance.md b/content/governance.md
index 096ed44..3e2912d 100644
--- a/content/governance.md
+++ b/content/governance.md
@@ -12,13 +12,13 @@ To support that code, we need infrastructure and funding, to run servers and sup
There are seven board members, aside from temporary vacancies. The current members are:
-* [Alyssa Rosenzweig](https://rosenzweig.io) (treasurer).
-* [Davide Cavalca](https://github.com/davide125) (administrator).
-* [Neal Gompa](https://royalgeekworld.com/) (secretary, treasurer).
-* [James Calligeros](https://social.treehouse.systems/@chadmed).
-* [Janne Grunau](https://social.treehouse.systems/@janne) (administrator).
-* Sasha Finkelstein.
-* [Sven Peter](https://social.treehouse.systems/@sven) (administrator).
+* [Alyssa Rosenzweig](https://rosenzweig.io) (treasurer).
+* [Davide Cavalca](https://github.com/davide125) (administrator).
+* [Neal Gompa](https://royalgeekworld.com/) (secretary, treasurer).
+* [James Calligeros](https://social.treehouse.systems/@chadmed).
+* [Janne Grunau](https://social.treehouse.systems/@janne) (administrator).
+* Sasha Finkelstein.
+* [Sven Peter](https://social.treehouse.systems/@sven) (administrator).
The board is responsible for project governance, infrastructure, and money. It also acts as the ultimate arbiter in case of conflict, including code-of-conduct enforcement. The board meets monthly by video call to do business in meetings. Our meeting minutes are public.
diff --git a/content/merch.md b/content/merch.md
new file mode 100644
index 0000000..c8a79fe
--- /dev/null
+++ b/content/merch.md
@@ -0,0 +1,9 @@
+---
+title: Merch
+date: "2025-06-04T07:33:19-07:00"
+draft: false
+---
+
+# Asahi Linux merch
+
+If you'd like to buy Asahi Linux merch, you can do so on our [HELLOTUX store](https://www.hellotux.com/asahi). A portion of each sale is donated to the project.
diff --git a/content/support.md b/content/support.md
index c248054..1a8d90b 100644
--- a/content/support.md
+++ b/content/support.md
@@ -1,12 +1,12 @@
---
title: Support
-date: "2021-01-05T20:00:00+09:00"
+date: "2025-06-04T07:33:19-07:00"
draft: false
---
# Support Asahi Linux
-The Asahi Linux project is funded by individuals like you. If you would like to support us financially, head over to our project [Open Collective](https://opencollective.com/asahilinux).
+The Asahi Linux project is funded by individuals like you. If you would like to support us financially, head over to our project [Open Collective](https://opencollective.com/asahilinux) or to our [GitHub Sponsors](https://github.com/sponsors/AsahiLinux). You can also [buy Asahi Linux merch](/merch), which supports the project with each sale.
Porting Linux to Apple Silicon is no small task. Financial support will allow
us to buy hardware and fund contributors, allowing the project to advance at a
diff --git a/layouts/partials/footer.html b/layouts/partials/footer.html
index 6bab599..e69f0a1 100644
--- a/layouts/partials/footer.html
+++ b/layouts/partials/footer.html
@@ -12,8 +12,10 @@
diff --git a/static/img/blog/2025/08/lsw.png b/static/img/blog/2025/08/lsw.png
new file mode 100644
index 0000000..d9bc57a
Binary files /dev/null and b/static/img/blog/2025/08/lsw.png differ
diff --git a/static/img/blog/2025/08/npp.png b/static/img/blog/2025/08/npp.png
new file mode 100644
index 0000000..aaf4a60
Binary files /dev/null and b/static/img/blog/2025/08/npp.png differ
diff --git a/static/img/blog/2025/10/hollowknight.jpg b/static/img/blog/2025/10/hollowknight.jpg
new file mode 100644
index 0000000..a33c00d
Binary files /dev/null and b/static/img/blog/2025/10/hollowknight.jpg differ
diff --git a/static/img/blog/2025/10/nier.jpg b/static/img/blog/2025/10/nier.jpg
new file mode 100644
index 0000000..5c169fb
Binary files /dev/null and b/static/img/blog/2025/10/nier.jpg differ
+
+ 
+
+ 
+
+ 
+
+ 
Fedora Asahi Remix is the result of a close multi-year collaboration between the Asahi Linux project and the [Fedora Project](https://fedoraproject.org/). We've worked hard in order to bring you a fully integrated distro, cooperating closely to get improvements and bug fixes to users as quickly as possible. All of our Asahi platform-specific packages are in upstream Fedora and fully supported in Fedora Linux 41.
+