Die Dubiose Dev

Tent Pole Bungee End Caps

2026-09-03T00:00:00+00:00

These replacement end caps were designed to fit common carbon-fiber and fiberglass tent poles. They allow the internal bungee cord to be reattached after replacing a damaged pole segment. The cord passes through the opening in the cap and is secured at the end of the final pole section.

Easy & Delicious Camping Breakfast Burritos for the Lazy-ish

2026-08-14T00:00:00+00:00

Two burritos photographed by Caitlin Sar Campbell and licensed under CC BY-SA 4.0. All photos in this specific blog post are licensed under CC BY-SA 4.0

I was recently made aware that I had been using some mildly novel camping cooking techniques. Due to the strength of the reactions to said mildly novel cooking technique, I felt obligated to document and share my approach. Thus this blog post.

The Technique

The idea is that before you go camping you make your burritos, wrap them in aluminum foil, then vacuum pack them.

Because they are vacuum packed they take a bit less space, but more importantly they can be hygienically and conveniently placed in a cooler full of ice without any other special precautions.

Because they are wrapped in aluminum foil they can be warmed up in a pan without making the pan dirty at all. When you are done cooking and the pan is cooled, the pan can be stored away in a bag, completely clean and labor free.

You can even get a nice char if the burritos are relatively flat. In the above case I let it go too long.

The whole technique produces really filling, satisfying, and pleasant breakfasts with an absolute minimal effort. A total win for the music festival goer, or the hacker at the next hacker camp grounds.

Sample Recipe to Use

While the technique can be used with any sort of aluminum-wrappable food in theory I do think egg and cheese breakfast burritos really shine here. This is my favorite recipe that makes 8 burritos which in my experience hold for 5 days in an ice filled cooler.

Ingredients

8 flour tortillas
18 eggs
2 red bell peppers
1 large onion
gouda cheese to taste (for me ~200g)
salt and pepper
Monosodium glutamate (MSG)
Butter

Cooking Steps

The Filling

Mince the bell peppers and onion into fine pieces. Finer is better here.
Heavily butter a pan and sauté the onions and bell peppers till semi translucent and soft to the bite.
While the onions and bellpeppers cook, crack and scramble all 18 eggs, mix in some salt, pepper, and MSG till the mix is slightly too salty.
Add salt, pepper, and MSG to the onion / pepper mix till the mix is slightly too salty.
Turn the heat down and add more butter to the onion / pepper mix if the pan is dry or pieces are sticking to the bottom of the pan.
Quickly mix in the eggs while stirring continuously.
As you mix the eggs should start to firm up. The goal is to not build up any burnt brown eggs and keeping everything mixed and moving evenly.
As the eggs start to firm up, now is the time to add in the gouda cheese. Continue to stir continuously.
As the eggs continue to firm, remove the pan from the heat while continuing to stir. Stir until you are confident no burnt brown egg crust will form.

Making the Burritos

Use a spatula to divide the eggs into 4 even quadrants. Split each quadrant in half again such that you have 8 even sections of filling.
Place a 1/8 section of filling into a burrito and tightly wrap it being sure to fold in both ends.
Wrap the burrito in aluminum foil being sure to fold in both ends.
Repeat for all 7 remaining burritos.
Place all the wrapped burritos in the fridge to cool down. When cool proceed.
Vacuum seal the burritos. I normally recommend 2 per person for breakfast so I like to do 2 burritos / vacuum bag.
Toss them in the ice cooler or keep them in the fridge till you are ready to cook them.

Warming the Burritos Up

In a clean dry stainless steel (or any type of) pan place as many burritos as will fit across the flat bottom of the pan.
Place the pan on a burner and warm up the burritos.*

Cook time can vary dramatically depending on the equipment and environment, but in my experience 2-5min per side depending on preference and the like should work. Once you flip the burrito the top side should remain hot to the touch even a minute later.

That's it. Super simple and easy if you put in the prep work.

Travel Protector for the Arctic Summair Plus

2026-08-12T00:00:00+00:00

This simple protector addresses a small issue I have experienced while traveling with the Arctic Summair Plus Fan. The front "grill" can be pressed into the blades themselves causing interference. Undoing this requires effort and a sharp object to pop the "grill" back over the tabs. This simple protector stops this problem from happening.Designed in OpenSCAD.

Reflections on Running Bevy Workshops After GPN

2026-06-12T00:00:00+00:00

GPN24, photographed by Caitlin Sar Campbell and licensed under CC BY-SA 4.0.

Setup

Some time ago, I signed up to run a workshop at GPN24 in 2026.

Before doing so, I had the opportunity to volunteer at the Bevy workshop at RustWeek 2025, run by Bevy co-maintainer Alice I. Cecile.

Long story short, I very much liked the "here is a working game; improve it as much as your Rust and Bevy know-how allows" approach the RustWeek workshop took, and created a workshop modeled on the same approach.

While the workshop eventually went swimmingly, thanks to Jade, who volunteered to help as we were randomly talking, there were some differences at GPN that I would take into consideration. These differences aren't necessarily GPN-specific as much as they are specific to non-industry-centric, hacker/maker-centric events.

I wanted to document these here such that future Bevy workshop runners might be able to consider these points in advance.

Hardware Considerations

Situation

I think a major factor to consider when running Bevy workshops at GPN is that there is a lot more diversity in hardware compared to more industry-centric conferences.

While at RustWeek, the majority of the hardware consisted of M3/M4 Macs, several of the latest Framework laptops featuring dedicated GPUs, or other quite powerful modern hardware.

The story was very different at GPN. Here I saw people working on Steam Decks, self-built Cyberdecks, many older laptops, and a few newer machines. Notably, though not strictly related, there wasn't a single MacBook to be seen.

Part of this might be a result of relative socioeconomic diversity at GPN compared to RustWeek, for sure, but a large part of this comes from hacker conference culture in general. Better to have self-expressive, open-source, self-made hardware than not.

As a result, the initial compile times were horrendous, shining a worse light on Rust and Bevy than I would have liked. They ranged from 10 minutes to 40 minutes, depending on the machine, with an average around 20 minutes.

People were literally SSH-ing into remote machines to compile it there, only to find that the debug builds were too big to scp back in a reasonable time.

In the end, though, everyone did get the code running after the initial compile, including one participant who did the initial 40-minute compile twice after reading online that cargo clean could address compile bugs.

This being said, I think we can do better.

Possible Improvements

I have two possible improvements that could help, one of which is uniquely enabled by hacker-centric events.

1 - Bevy Feature Optimization

The workshop I ran just used the default Bevy features without any manual selection at all. I had considered trimming it down, but opted against it because I didn't want users to be confused if they added Bevy ecosystem crates that suddenly didn't work due to said missing features.

Looking back, I should have done this. I could have eliminated many of the image formats, audio formats, system-specific features like Android, custom cursor, zstd, and many more.

Having a slimmed-down build, I suspect, would have made many people happier with the workshop. While this isn't technically an accessibility issue in the strictest sense, it feels that way when you see people not able to work because of older hardware while others get a 10-30 minute "head start".

At the very least, it feels privileged not to try to make things better. Something I can improve on.

2 - Shared Compile Caches

This one is more unique. Hacker-centric conferences, in my experience at least in Europe, allow people to host and run servers on the conference network.

This enables the potential for a locally hosted shared compile cache.

Personally, I use sccache in my own CI/CD pipeline and in my Docker build environment for Steam targets with a locally hosted S3-compatible endpoint.

I think this could be used to speed up the workshop at conferences that allow for local hosting.

The workshop participant could run this single command and start compiling right away, transferring binaries to their machine and bootstrapping themselves past the pain point.

AWS_ACCESS_KEY_ID="ReadOnlyId" \
AWS_SECRET_ACCESS_KEY="ReadOnlyKey" \
SCCACHE_BUCKET="workshop" \
SCCACHE_ENDPOINT="OnLanIpOrDns" \
RUSTC_WRAPPER=sccache \
cargo build

One could pre-populate it with x86_64 and aarch64 artifacts, and people would be on their way MUCH faster.

Software Considerations

Situation

Like with hardware, GPN-like conferences provide a very unique and diverse software environment. No macOS, no Windows, but a ton of Linux. Not just your Ubuntu, Debian, and Fedora either. The workshop featured many Arch and NixOS machines, several Fedora and Debian machines, a Void Linux machine, and a SteamOS machine.

While it was really cool to see Bevy running on such a diverse series of ecosystems, this led to several issues with setting things up to compile properly.

Particularly with NixOS and SteamOS.

Possible Improvements

While this is a hard one to address outside of the existing Bevy Linux-specific guides, I do think there is more to be done.

At the very least, workshops should aim to provide a NixOS flake. It was pretty simple, and Jade ended up distributing it to the NixOS participants.

I do think there is a better general solution though that should at least be considered, this being distrobox.

Distrobox is, in essence, scaffolding around OCI images (think Docker or Podman images) that lets users do things inside of those OCI images. You could distribute the workshop as a small (6 to 60 MB) image hosted on Docker Hub or GHCR.

The workshop participant could get Bevy running in a pre-set-up environment with literally two commands.

distrobox enter --name mybox --image ghcr.io/orgLocation/workshop:eventTag
cargo run

Distrobox works virtually anywhere, including VERY out-there environments like SteamOS or Void Linux and is trivial to install.

Location Considerations

This one was simpler but is still worth considering. If you are organizing a workshop, make sure there are plenty of power outlets. Compiling Rust is a battery killer, and participants can focus more on creativity if they don't have to worry about their 2023 laptop battery dying mid-recompile.

Conclusion

I hope future workshop runners can learn from my thoughts and experiences here. I know I will be changing things quite a bit to make things as nice as I can going forward.

This all being said, no one is entitled to more free labor than a volunteer workshop runner is willing to give. No judgment should be made if people go a different route.

Bevy glTF Considerations

2026-03-07T00:00:00+00:00

The situation at hand.

The amount of work that has been put into the Bevy glTF system is clear and evident. There is a ton of functionality that works really well and helps the engine shine.

In working on my game and continuing to learn the Bevy codebase, there is an issue that I think, while not threatening now, will only continue to grow into a larger and larger problem as time goes on.

This is the state of the gltf-rs dependency that Bevy uses in the bevy-gltf crate.

This crate is not well maintained, to the point where the same issue has been submitted multiple times over the years.

2023 - https://github.com/gltf-rs/gltf/pull/392
2025 - https://github.com/gltf-rs/gltf/pull/456
2026 - https://github.com/gltf-rs/gltf/pull/467

All three of these are for the same issue, adding KHR_texture_basisu support, and in my opinion all three were/are clean implementations against the existing gltf codebase.

If you look at the outstanding PRs, most of them are for adding one or another of the Ratified Khronos Extensions .

This is where the fundamental issue arises. While these extensions are not part of the core glTF 2.0 specification, they are de facto needed in order to use glTF as a modern 3D asset standard, particularly where glTF/GLB is the primary and preferred asset format.

As Bevy becomes more and more widely recognized as a game engine, it will become stranger and stranger that the only real options for textures are JPEG and PNG, both with their own issues and non-native GPU deficiencies.

Even worse, in my book, is telling current and future Bevy developers that "Bevy sort of hacks in KTX2 texture support in glTF files, but you need to use a special tool that turns your compliant glTF file into a non-compliant one BUT IT WORKS IN BEVY!"

What should we aim for?

Before continuing to consider resolutions, I think considering what would be desirable is worth doing.

Long Term

From a developer perspective, the ideal goal would be to make the glTF/GLB experience a first-class one.

The developer should be able to use glTF/GLB files without fear, without worrying about compatibility or the need to hack things in, in the same way that a Unity developer imports .unity assets knowing things will go smoothly.

Technologically speaking, I think this means we aim for FULL compatibility with all ratified Khronos extensions.

This is less daunting than it may seem. We already handle a good amount of these, and just need to parse the glTF JSON to hand it off to the relevant existing Bevy code.

Others are already in progress.

Others will need new code in Bevy or elsewhere.

In addition, I would propose that we consider adding selected vendor extensions including EXT_texture_webp and EXT_texture_avif (if we have AVIF support in the engine already). These are less important, but would lean into the first-class developer experience.

Short Term

In looking at what level of expanded glTF support we see in other game engines, we see this:

Extension	Godot	Unity	Bevy
`KHR_animation_pointer`	X*
`KHR_draco_mesh_compression`	X*	X
`KHR_lights_punctual`	X*	X	X
`KHR_materials_anisotropy`	X*		X
`KHR_materials_clearcoat`	X*	X	X
`KHR_materials_diffuse_transmission`	X*
`KHR_materials_dispersion`	X*
`KHR_materials_emissive_strength`	X*		X
`KHR_materials_ior`	X*	in progress	X
`KHR_materials_iridescence`	X*
`KHR_materials_sheen`	X*	in progress
`KHR_materials_specular`	X*	in progress	X
`KHR_materials_transmission`	X*	in progress	X
`KHR_materials_unlit`	X*	X	X
`KHR_materials_variants`	X*	X
`KHR_materials_volume`	X*	in progress	X
`KHR_mesh_quantization`	X*	X
`KHR_texture_basisu`	X*	X
`KHR_texture_transform`	X*	X	X
`KHR_xmp_json_ld`	X*
`EXT_lights_image_based`	X*	in progress
`EXT_mesh_gpu_instancing`	X*	X
`EXT_meshopt_compression`	X*	X
`EXT_texture_webp`	X*
`KHR_materials_pbrSpecularGlossiness`	X*	partial
*Godot docs don't list supported and unsupported extensions, but looking through the source I found nothing missing.
Unity imports via glTFast

I propose that, short term, we aim to be a superset of Unity, focusing on supporting the extensions they have that we don't.

Short term, we may consider adding EXT_texture_webp as well, since this would be trivial once we decide on an approach.

Potential Resolutions

There are several resolutions I could foresee. BUT the only resolution that I think would be actively harmful would be to continue to base bevy_gltf on gltf-rs without a long-term plan.

We should not pull a Warhammer 40k and build an empire around a slowly rotting corpse of a project. Not without a plan to lean less on the corpse at least.

Best Case - gltf-rs revival

If we can revive the project, either through a maintainer of gltf-rs becoming active or through the project adding a Bevy-vouched-for approver, this would be the best case.

With an understanding that the gltf-rs project owners may have certain requirements, we could agree to only make changes that do not interfere with those requirements.

This requires some buy-in from the gltf-rs owners, which may be impossible.

This would allow us to make these changes to benefit Bevy and the community as a whole.

Case 2 - gltf-rs fork

Another option is for a group of people to maintain a fork of the existing project. It will be more work, but the crate is well documented and has a test suite that could be expanded to reduce future labor.

Here we could start by cherry-picking the relevant existing PRs, and we would be halfway done with our long-term goals.

The advantage here is that we could use upstream labor in our efforts to maintain the crate. The whole wider community benefits.

Case 3 - do raw glTF I/O in-house as part of bevy-gltf

This is less bad than one might think. Right now we use gltf-rs and wrap our "user space" GltfExtensionHandler trait around it.

There are some existing extensions that are implemented in-house, namely khr_materials_anisotropy, khr_materials_clearcoat, and khr_materials_specular.

I think this approach is valid. My primary concern here is that we are still wrapping the code around a slowly rotting corpse. My secondary concern is that we lose out on upstream efforts.

I think there is a path forward if we take this approach.

In addition to adding all the extensions that make for a predictable first-class glTF experience, we slowly handle the core glTF features as well using the same code paths.

We have the khr_materials_anisotropy extension, but we could then add core_node_hierarchy that would handle a core glTF 2.0 feature.

We could do this slowly over time, one piece at a time, replacing one core feature at a time until we have core_*, where all glTF 2.0 core functionality is handled and wrapped around nothing.

This would let us slowly migrate away without replacing the world.

Conclusion / Key Points

If glTF is our preferred asset format, we should make using it a first-class experience.
The root cause of the existing glTF problems is gltf-rs not being well maintained.
We can fix this root cause by reviving the core project, forking it, or bringing it in-house.
No matter which way we go, we SHOULD & MUST not build an empire on a rotting corpse.

Kungsfors Protector Sleeve

2026-02-19T00:00:00+00:00

This protective sleeve was designed to fit over the IKEA Kungsfors magnetic knife holder. The sleeve prevents knife edges from making direct contact with the metal surface, reducing the risk of chipping when placing or removing knives. The design slides over the holder and stays in place during normal use.

Learning Engrammer

2025-05-05T00:00:00+00:00

New Keyboard New Layout

I recently decided to buy a new keyboard after my the pleather shedding issue with trusty Microsoft ergonomic keyboard became too severe to ignore. As well as that keyboard has served me, when it started polluting my home something needed to be done.

After some research I landed on Keycron’s Q10 Max. The build quality is excellent, and the Alice style layout lets me stay in an ergonomic, but not too radical (i.e. split) form factor.

The Q10 Max being wireless let me continue on my path towards a clean, clutter free, and wire free desktop.

I decided that, while I was at it I should consider alternative keyboard layouts. After all a new keyboard requires relearning muscle memory, why not double down?

I considered a few layouts, namely Graphite, Engram, Gallium, and Hands Down.

An important thing I learned in my research is that there seems to be a definitive break between post and pre covid layouts, with post covid layouts being substantially more well designed.

I ended up going with Engram variant because I liked the emphasis on roll-ins, and the inner column punctuation.

I went with the Engrammer because the brace and bracket locations in Engram where not great for software development. Engrammer has the same letter layout as engram, except with a more programmer centric symbol layout.

What I Did And How I Learned

Learning Engram was extremely painful. I committed to a cold turkey approach and switched both my laptop and desktop layout to use Engrammer on day one.

I also did 30 minutes of daily keyboarding practice on keybr.com (which has many alternative layouts build in, including engram build in) daily for one month.

The learing process went something like this:

Week 1

Pure Agony. If I worked a traditional job I surely would have been fired. My productivity dropped to like 5% on normal.

I couldn’t even play video games normally. I had to remap every game I played to use the new layout. (I know I could have switched back for games, but I wanted to commit 100%.)

Week 2

Very painful. Posable to code but barely.

Wondered why I decided to do such a dumb thing.

Week 3

Slow, but I can work.

At this point it felt like things where starting to come together.

Week 4

Feeling slow but better.

Over the hump for sure.

The main thing that helped was consistency. I practiced every day even if it was the only thing I did that day. My life basically revolves around typing in one form or another so even on bad days I had some motivation.

If I had one tip for people who want to learn a new key layout it would be to practice every day.

Impact

It's been just over a month and I continue to practice daily. Thing get better daily. This blog post probably only took 20% longer to type than it would have if I used QWERTY/Z.

Funny thing is that I now struggle with QWERTY/Z.

Overall typing feels better now and I am happy.

Would I recommend learning a new layout? Yes, but only if you can commit hard. Otherwise the productivity drop would be too drastic for too long.

Box Fan Privacy Screen

2025-04-05T00:00:00+00:00

This privacy screen was designed to provide privacy by replacing the front grate of a box fan. It allows air to flow threw without allowing look in. Perfect if you want cool air and privacy! The grate was designed for a Lasko box fan but should work with other box fans.

280mm x 150mm Crate

2025-04-04T00:00:00+00:00

This 280mm x 150mm robust crate was designed to hold root vegetables, but could be used for any heavy goods. This is being released as one of many simpler designs I made over the years.

Nasal Strip Holder

2025-04-03T00:00:00+00:00

This simple nasal strip holder was designed to be placed on a nightstand and keep things organized. The design is simple and trivial to change. This is being released as one of many simpler designs I made over the years.

Roller Blind Window Clip

2022-05-28T00:00:00+00:00

This roller blind window clip was designed to be compatible with Gardinia. This clip was designed after the original one was broken and a replacement was needed. This design is definitively stronger than the original design.

PanelDue 7i Case for the Railcore II

2020-03-24T00:00:00+00:00

This is my simple PanelDue 7i case for the Railcore II.

Secret Hitler Name Plaques

2019-11-17T00:00:00+00:00

A quick multi material 3d print project I put together for a friend. These are used in the VERY fun (and freely available) Secret Hitler Game. If you like the game I would encourage you to support the creators by purchasing a pre printed card set from them.

Tall Laptop Stand

2019-09-06T00:00:00+00:00

This project was my first ever venture into 3D design. I had just acquired a 3D printer and wanted to print something out for myself. This was created in "Parts" mode in FreeCAD. In the end the design worked out well and I used it for many years.