Update hugo and tweet embed syntax

This is the version in Arch/Asahi these days, so let's bump it to make things easier ^^ Signed-off-by: Asahi Lina <[email protected]>
AsahiLinux · Mar 20, 2023 · b897bdd · b897bdd
1 parent 845c333
commit b897bdd
Show file tree

Hide file tree

Showing 5 changed files with 10 additions and 10 deletions.
diff --git a/.github/workflows/gh-pages.yml b/.github/workflows/gh-pages.yml
@@ -17,7 +17,7 @@ jobs:
       - name: Setup Hugo
         uses: peaceiris/actions-hugo@v2
         with:
-          hugo-version: '0.87.0'
+          hugo-version: '0.110.0'
 
       - name: Build
         run: hugo --minify

diff --git a/content/blog/2021/08/14-progress-report.md b/content/blog/2021/08/14-progress-report.md
@@ -25,7 +25,7 @@ Instead, a much safer approach that has been used by projects such as [Nouveau](
 This is very different from a typical virtual machine, which is designed to run a guest OS on top of a host OS, with a full set of virtualized hardware. Our hypervisor, which is built on our [m1n1](https://asahilinux.org/2021/03/progress-report-january-february-2021/#playing-with-hardware) bootloader and hardware experimentation tool, is a completely bespoke implementation. It is designed to mostly stay out of the way of the guest OS, running it in an environment as close to bare metal as possible, while just transparently intercepting and logging hardware accesses. Thus, macOS "sees" the real M1 hardware, and interacts with it as normal - complete with a full accelerated desktop.
 
 {{< captioned caption="This tweet was posted from Safari on macOS, running on the hypervisor" >}}
-    {{< tweet 1397963184959418370 >}}
+    {{< tweet user="AsahiLinux" id="1397963184959418370" >}}
 {{< /captioned >}}
 
 Since the hypervisor is built on m1n1, it works together with Python code running on a separate host machine. Effectively, the Python host can "puppeteer" the M1 and its guest OS remotely. The hypervisor itself is partially written in Python! This allows us to have a very fast test cycle, and we can even update parts of the hypervisor itself live during guest execution, without a reboot.

diff --git a/content/blog/2021/10/06-progress-report.md b/content/blog/2021/10/06-progress-report.md
@@ -67,7 +67,7 @@ Once we have a stable kernel foundation, we will start publishing an "official"
 As part of reverse engineering the CPU frequency hardware, I found myself needing to run macOS under the m1n1 hypervisor with full SMP support... so I made it happen! The hypervisor can now expose all 8 CPU cores to the guest, and virtualizes the CPU startup hardware. This is not only important for reverse engineering SMP-related features, it also means it now boots almost as fast as on bare metal!
 
 {{< captioned caption="The hypervisor, now with 8 times the cores" >}}
-    {{< tweet 1438152384165728257 >}}
+    {{< tweet user="AsahiLinux" id="1438152384165728257" >}}
 {{< /captioned >}}
 
 This also makes it even more practical to use for testing Linux; there is very little reason not to run under the hypervisor during most kernel development now. This makes things much easier for anyone without a serial debug cable, as the hypervisor provides a virtual UART over USB, as well as interactive debugging features.

diff --git a/content/blog/2022/07/18-release-and-progress-report.md b/content/blog/2022/07/18-release-and-progress-report.md
@@ -112,7 +112,7 @@ The OpenBSD installer knows about the magic Apple partitions, so even if you cho
 
 I know what you’re all thinking… what about the GPU?
 
-{{< tweet 1537828477352615936 >}}
+{{< tweet user="LinaAsahi" id="1537828477352615936" >}}
 
 Good news! A couple months ago, [Asahi Lina](https://twitter.com/LinaAsahi) joined our team and took on the challenge of reverse engineering the M1 GPU hardware interface and writing a driver for it. In this short time, she has already built a prototype driver good enough to run real graphics applications and benchmarks, building on top of the existing Mesa work. The proof of concept uses m1n1 via a USB connection and runs the driver remotely, so it is bottlenecked by USB bandwidth, but she has also demonstrated that the GPU proper renders the GLMark2 phong shaded bunny scene at over 1000FPS, at 1080p resolution. This fully open source stack passes [94%](https://twitter.com/LinaAsahi/status/1546301886147731457) of the dEQP-GLES2 test suite. Not bad!
 

diff --git a/content/blog/2022/11/29-gpu-story.md b/content/blog/2022/11/29-gpu-story.md
@@ -68,7 +68,7 @@ Since getting all these structures right is critical for the GPU to work and the
 
 At first most of the driver was really just [a bunch of hardcoded structures](https://github.com/AsahiLinux/m1n1/blob/main/proxyclient/experiments/agx_1tri.py), but eventually I managed to get them right and render a triangle!
 
-{{< tweet 1532028228189458432 >}}
+{{< tweet user="LinaAsahi" id="1532028228189458432" >}}
 
 This was just a hacked up together demo, though... before starting on the Linux kernel driver, I wanted to make sure I really understood everything well enough to design the driver properly. Just rendering one frame is easy enough, but I wanted to be able to render multiple frames, and also test things like concurrency and preemption. So I really needed a true "kernel driver"... but that's impossible to do in Python, right?!
 
@@ -78,7 +78,7 @@ Could I run [Inochi2D](https://inochi2d.com/) on top of Mesa, with Alyssa's Mesa
 
 It's so ridiculous that it worked! ✨
 
-{{< tweet 1537828477352615936 >}}
+{{< tweet user="LinaAsahi" id="1537828477352615936" >}}
 
 ## A new language for the Linux kernel
 
@@ -108,11 +108,11 @@ The more I worked with Rust, the more I fell in love with it! It feels like Rust
 
 The driver slowly came together, and on September 24th I finally got kmscube to render the first cube, with my brand new Rust driver!
 
-{{< tweet 1573488347250536449 >}}
+{{< tweet user="LinaAsahi" id="1573488347250536449" >}}
 
 And then, something magical happened.
 
-{{< tweet 1575345368018997248 >}}
+{{< tweet user="LinaAsahi" id="1575345368018997248" >}}
 
 Just a few days later, I could run a full GNOME desktop session!
 
@@ -126,7 +126,7 @@ Of course, there are always unsafe sections of code, but since Rust makes you th
 
 Oh, and there's also error and cleanup handling! All the error-prone `goto cleanup` style error handling to clean up resources in C just... vanishes with Rust. Even just that is worth it on its own. Plus you get real iterators and reference counting is automatic! ❤
 
-{{< tweet 1583498896847667216 >}}
+{{< tweet user="LinaAsahi" id="1583498896847667216" >}}
 
 ## Joining forces
 
@@ -143,7 +143,7 @@ And since the GPU power management is handled by the firmware, all that just wor
 
 What about Vulkan support? Don't worry... [Ella](https://tech.lgbt/@ella) is working on that! ✨✨
 
-{{< tweet 1584316751591878656 >}}
+{{< tweet user="EllaStanforth" id="1584316751591878656" >}}
 
 ## What's next?