deivid

There was a Varlink talk[0] a few days ago at All Systems Go, in that talk, Lennart mentioned that JSON is unfortunate (primarily due to no 64 bit ints) but it has the surprising benefit of being able to understand the bus messages when using `strace` for debugging.

[0]: https://www.youtube.com/watch?v=emaVH2oWs2Y&list=PLWYdJViL9E...

Not exactly rust-in-kernel, but I've been using Aya[0] to write ebpf programs in Rust and it is quite nice. The verifier is still a bit trigger-happy with some constructs, but it is manageable.

[0]: https://aya-rs.dev/

Linux can boot quite quickly with the right settings, I've written about it at [0], but distros (reasonably) build very generic kernels and initramfs, which are not particularly fast to boot

[0]: https://blog.davidv.dev/posts/minimizing-linux-boot-times/

I don't think so, I run a CI on a VisionFive2 and it is terribly slow, takes ~8x compared to my Ryzen 3600 CPU. It's not helped by also having fairly limited IO speed on the NVMe side (board issue? unclear)

I changed banks to one that supports "e.dentifier" -- a physical 2fa device. Unsure for how long it will be supported, as they are pushing the app quite heavily

You can also put one together with an ESP32 and a gps receiver for maybe $15

There are plenty of examples online, but this is my "cool clock" https://github.com/DavidVentura/esp-ntp

Amazing! I love projects that bring some new features to classic hardware; I did something similar for my dad's 50th birthday[0].

[0]: https://blog.davidv.dev/posts/revamping-an-old-tv-as-a-gift

Thanks for the detailed answer

> extensibility

This is something that irks me right now, but at my current knowledge level (~0) it didn't feel right to even mention:

If Kubernetes pushes everything out (CSI, CNI, Cloud provider integration, LoadBalancer, ...), doesn't it become "just a control loop runner"?

I'm sure there's value in that, but I can imagine that most people running clusters would make different choices for various options, landing you with _every cluster being unique_, which feels wrong somehow.

Using custom/external metrics is exactly what I was looking for, thanks!

I think my misunderstanding comes from the distinction between "first party" sensors (CPU scaler) and "third party" sensors (via "external metrics").

Is there a reason for this distinction? Will the CPU scaler eventually be pushed out of k8s as well?

I've not yet gone down that path, in which other ways does your workload need to adapt? I understand that you may want to get more value out of logs, and include side-cars, you may want inter-pod encryption and include service meshes, etc; but that'd be something that requires extra complexity in any setup

I definitely do not need a very large FPGA, though navigating this space as a newbie is quite hard -- I've built some small projects (serial multiplexer and a WASM CPU) on the Tang Nano 9k/20k

I think the difference between a $220 board and a $1000~ board is quite large for a hobby project

> Kubernetes has been pruning out vendor-specific code for a while now, moving it out of tree.

I wasn't aware, but it makes sense, and explains the current "confusing" state.

Any dev kit you can buy in the low hundreds? I thought the UltraScale was in the low _thousands_

The screamer looks interesting, using Displayport Alt mode could work!

The end goal in this series is to use an FPGA to build a display adapter, I've gotten a Tang Mega 138k [0] to start the process but there is not a lot of documentation, so it is taking a while

If you got recommendations for other (cheap) FPGA boards with PCI-e hard IP, do let me know.

[0]: https://wiki.sipeed.com/hardware/en/tang/tang-mega-138k/mega...

I've written a little bit about writing a driver & using QEMU to create a custom device for it at [0] & [1]

[0]: https://blog.davidv.dev/posts/learning-pcie/

[1]: https://blog.davidv.dev/posts/pcie-driver-dma/

It's not the only other option! It's not less yucky, but you can creatively stomp on the vDSO functions which back the time-related functions (gettimeofday, clock_gettime, time); I've written about it at [0] and have a "library" (more like a proof of concept) at [1].

[0]: https://blog.davidv.dev/posts/cursing-a-process-vdso-for-tim...

[1]: https://github.com/DavidVentura/tpom

I'd kinda hoped that they took so long to go arm64 because they generalized "1 architecture -> N architectures"

I wonder if they'll start supporting risc-v soon.

I've been using github-act-runner on top of a local Nomad cluster to run some of my builds on risc-v, arm64 & x86-64, it's fine, but a bit of a hassle to set up

The Product-minded Generalist post does not seem to be open right now, is that accurate?

You could try Marginalia's small web / blogosphere modes at https://search.marginalia.nu/

I've followed this series and it's very good https://learn.lushaylabs.com/tang-nano-series/

Unikraft is really cool, but Linux is not necessarily the blocker. You can boot to PID1 in firecracker in ~6ms, see my experiments: https://blog.davidv.dev/minimizing-linux-boot-times.html

I've built a bunch of things:

A snapcast client, which can play audio synchronized on multiple rooms

https://github.com/DavidVentura/esp-snapcast

An stratum-1 NTP _server_ (read: gets its time from GPS), and displays time with unreasonable precision (not necessarily accuracy!)

https://github.com/DavidVentura/esp-ntp

A few HUB75 signs which display public transport status (the public transport bits are not published anywhere yet)

https://github.com/DavidVentura/hub75-esp

An "on-air" sign that turns on/off if my wife or I join a meeting (based on camera/mic usage, for Linux and Mac)

https://github.com/DavidVentura/on-air

A purely decorative sign that looks like a pixelated fire

https://github.com/DavidVentura/matrix-fire

A kindle-controlled bedside lamp (just mqtt, but functionality is priceless - blogpost is unrelated but it's the only video I've got)

https://blog.davidv.dev/building-an-mqtt-client-for-the-kind...

An HDMI switcher (just a GPIO toggle) & a full-house blinds controller (just a relay hooked to the central, manual system)

https://blog.davidv.dev/extending-the-capabilities-of-dumb-d...

I've been thinking about starting a project to build a 'display adapter', but I've gotten stuck before starting as I wasn't able to figure out what is the communication protocol between UEFI's GOP driver and the display adapter. I've been trying to piece it together from EDK2's source, but it's unclear how much of this is QEMU-specific

I implemented a Snapcast client[0] in Rust, with the goal of having synchronized speakers, using only an ESP32 per speaker. I didn't get to the ESP32 part that weekend though, probably it'll come on the next one.

[0]: https://github.com/DavidVentura/snapcast-client

You can get an uncompressed Linux image (built with only virtio support, including SMP and networking) under 12MB; it's not 2, but also not 30MB. This is without LTO, so you could probably get it lower.

I spent a few hours building the smallest kernel that'd boot in Firecracker ( https://blog.davidv.dev/minimizing-linux-boot-times.html ), got it booting in 6ms with network support, which opens up some interesting use-cases.

The constraints fuel creativity, but it also pushed me to start writing a Lua compiler for PicoPico, which shows promise but is also a massive scope creep and mostly the reason I've not worked on PicoPico for a while

With Lua's design, each bytecode operation requires a bunch of memory accesses, these microcontrollers only have a limited amount (~500KB) of SRAM, so you need to place this memory on PSRAM (RAM over SPI) which has "significant" latency for these microcontrollers.

It's definitely possible to use standard Lua and run _some_ of the Pico8 games, but not all.

Lua itself does not require a lot of memory, but PICO-8 guarantees 2MiB of usable RAM