T4T5

Running DaVinci Resolve on a Framework 13 with Omarchy

Tue, 20 Jan 2026 00:00:00 GMT

When I decided to install the DaVinci Resolve video editor on my Framework laptop (running Omarchy btw), little did I know that I was about to embark on a journey full of obscure errors and edge cases. Apparently running it on Linux, while technically possible, is often so hard that it has almost become a meme at this point. I was, however, dead set on not giving up, and after a lot of tweaking with some help from Claude Code, I eventually got everything working as expected!

I’m posting what I did here to save others from going through the same headaches as I did.

TLDR: Use davincibox to run DaVinci Resolve in a containerised Fedora instance. Use ROCm and override the GPU environment variable so that it thinks that you have an AMD Radeon RX 7900 (gfx1100).

1. Install container dependencies

First we download all the packages that our Fedora containerisation will use.

sudo pacman -S podman distrobox lshw crun

2. Change user permissions

DaVinci Resolve needs additional user permissions to access the GPU’s rendering capabilities.

sudo usermod -aG render,video $USER

Log out and back in for the changes to take effect (or restart your computer). You can verify that the permissions are set correctly by running the following command:

groups
# > 'render' and 'video' should show up in the output!

3. Download DaVinci Resolve

Get the installer from the official website (yes, you will need to fill in a registration form, but it’s fairly quick). You’ll get a zip containing a .run file.

4. Set up davincibox

DaVinci Resolve’s Linux installer is built specifically for RHEL-compatible distros - Blackmagic doesn’t officially support Arch Linux. To work around this, we use davincibox.

Clone the davincibox source code and move the .run file from the previous step into the same directory so that we can run the setup script:

git clone https://github.com/zelikos/davincibox.git
cd davincibox
./setup.sh DaVinci_Resolve_*.run

5. Install ROCm

Without access to your GPU, DaVinci Resolve would be far too slow even for basic video editing. ROCm provides GPU acceleration for AMD graphics cards, so we install it inside the container:

distrobox enter davincibox -- /bin/bash

# once you're in the container, run:
> sudo dnf install rocm-opencl
> exit

6. Override the GPU version

If you have a Framework with an AMD chip, you will most likely see this error if you try to open the app:

My Framework 13 has a Radeon 840M (gfx1152), which isn’t officially supported. However, you can still make it work if you trick ROCm into thinking that you have a Radeon RX 7900 (gfx1100).

To do this, edit the file ~/.local/share/applications/DaVinciResolve.desktop in your favourite text editor and change the Exec line to:

Exec=distrobox-enter -n davincibox -- env HSA_OVERRIDE_GFX_VERSION=11.0.0 /usr/bin/run-davinci /opt/resolve/bin/resolve %u

7. Fix the scaled-down UI

DaVinci Resolve should now technically open without any errors, but you’ll notice when you launch it that the UI will be almost unusably small.

To fix this, navigate through the small UI and create a dummy project - this will reveal the menu bar for the app.

In the upper-left corner, click “DaVinci Resolve” -> “Preferences”. Then click the “User” tab, go to “UI Settings” and set the “UI Display Scale” to 200%.

Save and restart the app.

Congratulations, you are now ready to edit videos on your Framework laptop! 🎉

Some final notes:

The free version of DaVinci Resolve on Linux doesn’t support H.264/H.265 videos (for weird licensing reasons). You’ll need to convert H.264/H.265 videos to MJPEG or DNxHR encoding before importing them:

ffmpeg -i input.mp4 -c:v mjpeg -q:v 3 -c:a pcm_s16le output.mov

The Radeon 840M has limited compute units, so this setup is best suited for lightweight video editing only. If timeline playback seems slow, right-click clips -> “Generate Optimized Media” or enable Playback -> “Proxy Mode”.

The return of plaintext productivity

Thu, 08 Jan 2026 20:20:00 GMT

The premise of “plaintext productivity” is simple: most software today is overengineered, and the real secret to productivity is to return to radically simpler tools. Once you switch from whatever SaaS-based todo app you’re currently using to a single long todo.txt file, you’ll avoid a million distractions and actually get shit done.

I’ll admit that this concept always seemed slightly performative to me. The enthusiasm from people promoting it often seemed more rooted in ideology than actual productivity (“screw big tech, own your data!”)

But recently I’ve changed my mind and become a religious promoter of plaintext productivity myself. That’s because there’s a new, incredibly compelling reason to adopt this workflow:

LLMs love plaintext files.

This might seem obvious to many, but I don’t think we’ve fully realised all the implications.

CLI tools like Claude Code and OpenCode keep showing people that when their data is organised as simple plaintext files in a logical directory structure, they perform extremely well at almost any task.

Some recent examples:

There are a thousand other stories like this all pointing to the same pattern: the “file over app” philosophy is suddenly paying massive dividends in the age of AI agents.

If a workflow is hard to automate today, it’s almost certainly because:

The state lives on someone else’s computer, or
it uses an obscure or proprietary file format

Sure, sometimes you can still get the data through authenticated API requests and MCP, but it’s still an order of magnitude more complicated, restrictive, and slower than simply letting an agent go wild with find, grep and ls in a folder with raw text files.

My own computer habits are changing rapidly because of this. I used to be more of a visual person: macOS, polished app UIs, everything had to feel intuitive. Now the visual interface has become secondary. The main thing I care about is that my data is readable by Claude. I write as much as I can in markdown, and spend an increasing amount of time migrating data from all my apps to plaintext formats like CSV, just to see what an agent can do with it.

What happens when everyone starts optimising their software for LLMs over humans?

My hunch is that we’ll all want to make our data a lot simpler, more readable, and more portable.

Turns out the plaintext productivity guys were right all along.

The Bitcoin Halving will be reorged

Fri, 26 Jan 2024 00:00:00 GMT

Every four years (or every 210,000 blocks to be precise) Bitcoin’s issuance per block gets cut in half. So far, we’ve never really placed much importance on who actually mines the block that triggers the next halving cycle, we just have a short moment of celebration and then move on.

But this year’s Bitcoin halving is not like other halvings. Block 840,000 will likely have the most valuable block reward in Bitcoin’s history by far.

This is all because of one man—Casey Rodamor, the creator or the Ordinals protocol. He has almost single-handedly created the biggest MEV opportunity ever in Bitcoin, and it will be impossible for miners to resist.

To see this more clearly, let’s do a quick analysis to estimate what the value of block 840,000 is.

The Epic Sat

At the core of Casey’s Ordinal theory is the concept of assigning serial numbers to individual satoshis and tracking them over time.

Once satoshis become non-fungible, it naturally follows that some sats will be considered more valuable than others, maybe because its number is aesthetically pleasing, or because it was involved in a transaction of historic importance.

A list of popular traits (or “satributes”) that an individual satoshi can have. From ord.io

One of the most popular ways of categorising sats today is using the Rodarmor Rarity system, which tracks the events triggered by Bitcoin’s protocol rules (i.e. new blocks, new difficulty adjustment periods, new halving periods) and assigns extra importance to the first sat that gets created in each one.

The different levels of sat rarity, according to Casey Rodarmor

While some consider this way of viewing sats nothing more than a frivolous hallucination, it’s impossible to deny that it has found its niche within a community of Bitcoin collectors and archeologists.

The floor price of a single Uncommon sat on MagicEden is currently $400 (0.01 BTC), and Sotheby’s recently sold a Rare sat for over $100,000 (2.71 BTC)!

And yet, none of these previously sold sats will be nearly as valuable as the sat that is set to be mined in block 840,000 – the Epic sat.

An Epic sat is created once every halving, so the total supply currently stands at just 3! As none have been sold yet, their market value is still a mystery. However, knowing that Rare sats are selling for $100k a pop, and that the supply of those is 100 times bigger than Epic sats (410 vs 3), we can safely say that the Epic sat will probably be valued at least 10 times higher than a Rare sat. That puts its price at around 1 million dollars (or roughly 25 BTC at the time of writing).

Note that this price is what you could reasonably ask for if you decided to just sell it straight away. The smarter move would probably be to keep the sat and capitalise on the range of opportunities that it opens up, potentially generating a large income stream for years to come. As the number of inscriptions keeps increasing, the simplest and most obvious way to stand out from the noise is to inscribe your collection on a special sat.

The inscriptions in the Pizza Ninjas collection were all inscribed on “Pizza sats”, i.e. sats that were involved in the infamous 2010 Pizza transaction. The first inscription is on an Uncommon Pizza sat. The collection has a market cap of ~100 BTC.

Remember – not a single inscription has been made on an Epic sat yet. Whoever makes the first one could easily create a whole collection with that inscription as its parent in order for every piece to accrue value.

“Seize Ctrl” made the first ever inscription on a Rare sat, and then turned it into a collection of 405 pieces. The collection now has a market cap of ~30 BTC.

Estimated value of Epic sat in the Halving block: $1M+ (25 BTC)

So the existence of the Epic sat already makes this block extremely valuable. However, it pales in comparison to the next thing that block 840,000 will also contain.

The First Rune Token

The Runes protocol is a new token standard by Casey Rodamor that’s set to launch as soon as block 840,000 kicks in. As one would expect, we’ve already started to see multiple teams on X market their upcoming token as “The First Rune”.

January 22, 2024

January 23, 2024

The truth of course is that we won’t know for sure who gets to claim that title until the block is actually mined. But why is being first even important?

We can look at the BRC-20 ecosystem for a clue. The first ever BRC-20 token, ORDI, was created by domo in March 2023. The token has no utility or special attributes other than being the first of its kind, and yet it is still the most valuable BRC-20 token today, with a market cap of over 1 billion dollars.

Top BRC-20 tokens by market cap. From coingecko.com

By pretty much any standard, Runes is a much better designed protocol for fungible tokens than BRC-20 is, with longer potential staying power. A cautious projection suggests that the first Rune token, even if it has a ridiculous name and no utility whatsoever, will quickly amass a market cap of $1B+.

One very important difference between Runes and BRC-20 is that Runes don’t necessarily have to have a fair launch where the initial supply is zero and anyone can mint them. Teams that launch a Rune token have the ability to allocate (i.e. premine) it to themselves in the etching transaction.

This by itself makes it insanely attractive to be the team that launches the first Rune token. We don’t know what the premined team allocation for that first token will be (maybe there won’t even be one!), but it would seem like a huge wasted opportunity not to allocate at least a little bit to the creators, in order to secure their financial future forever.

In the world of smart contract platforms like Ethereum and Solana, it’s very common for the founders’ token allocation to be around 25% of the total supply. Again, let’s be extremely conservative and estimate that only 5% of the first Rune token’s supply is allocated to the team. At a 1 billion dollar valuation, that would still leave its value at a whopping 50 million dollars!

Estimated value of team allocation of first Rune token: $50M

So what will happen?

By conservative estimates, the data in block 840,000 is easily worth at least $50M dollars (or well over 1000 BTC). This is more than 200 times higher than the standard block reward, which at the time of writing is averaging ~6.5 BTC. In other words, block 840,000 is worth at least 2 orders of magnitude more than any other block before it.

This has never happened before, and dangling that huge money pot in front of miners will make it extremely hard for them to play by the usual rules. So what can we reasonably expect to happen in April this year?

Well, we know that mining pools like AntPool, SECPool and F2Pool have already started experimenting with Ordinal MEV by extracting rare sats from the blocks they mine.

AntPool extracting a Rare sat. Source: mempool.space

Similarly, the mining company Luxor made headlines last year by skipping the mempool and filling a whole block with a single inscription of a 4MB Taproot Wizard JPEG. Other pools like Terra Pool have since followed and turned the process of inscribing large files into a service they offer.

When you think about it, the cost to privately buy a block from a miner is really just the cost to cover the sum of transaction fees that they’re missing out on, plus a small premium. Those transaction fees currently average around ~$10,000, which really isn’t much at all.

The result is inevitable: block 840,000 will almost certainly not be a “normal” block where a miner just snaps up the highest paying transactions from the mempool. The prospect of a collaboration between a capital-rich team in the Ordinals space and a mining pool presents an overwhelmingly attractive opportunity. In fact, it would be foolish for the miner to leave that money on the table!

Consider a hypothetical situation where a project proposes to pay a miner 5 million dollars for the exclusive right to design a block:

The miner gets 500 times their usual fee income with virtually no extra effort.
Since the content of the block is arguably worth $50M+, the team that bribed them can easily capitalise on both the Rune and the Epic sat to earn at least 10 times the $5M that they spent, probably also with relatively little effort.

Given this situation, the biggest mining pools are likely being approached as we speak with very lucrative deals in preparation for the halving.

But what happens if two independent Ordinal teams strike deals with competing miners? This is the scenario where we’ll potentially see the mother of all reorgs.

If the miner is paid $5M to mine the halving block, and the next few blocks only have rewards of ~$125,000 each, they should theoretically be okay with missing out on the revenue of ~40 blocks. In other words, even if one miner gets there first, and their version of block 840,000 already has multiple confirmations, there will still be strong incentives for another miner to keep placing their bet on building on top of their version of block 840,000 instead. There is always that small chance that they find multiple blocks in a row and win the race.

So it seems almost inevitable to me that we’ll see the mother of all reorgs on Bitcoin this year. While I don’t know exactly how it will play out, one thing we know is that it will certainly be interesting, and eventually the dust will settle and new blocks will keep coming in as normal.

It also makes it clearer than ever why Bitcoin’s transaction fees need to go up over time. It’s currently too cheap for private parties to come in and bribe the operators of mining pools. If an NFT or token company can make miners dismiss a bunch of transaction in their favour, you can be sure that a state actor could do the same. The number of high-fee transactions in the mempool needs to go up to become more attractive to miners than private arrangements, or we risk eventually having a big problem.

How to connect your Umbrel node to Joule

Sat, 15 May 2021 00:00:00 GMT

Ethereum has a popular browser extension called MetaMask that makes it trivial for users to interact with DeFi apps from their browsers.

Fewer people are aware of the fact that Bitcoin has a great equivalent for its Lightning apps called Joule!

The Joule website

Thanks to Umbrel, it’s already much easier for average Bitcoin users to set up their own node and get started with Lightning. Connecting it to Joule takes this experience even further and makes it a joy to interact with LApps in your browser!

Curiously, there doesn’t seem to be any guides explaining how to use the two together (although there is a pull request aiming at make this pairing easier in the future).

Until then, here’s a step-by-step guide on how to make it work!

This guide assumes that you already have an Umbrel node up and running. We will be using the Chrome browser in this guide, but the Joule extension also works with Firefox, Opera and Brave.

Step 1:

Go to the Joule website and download the browser extension.

If you’re using Google Chrome, you will be redirected to the Chrome web store, and you’ll have to click “Add to Chrome”.

Step 2:

Open the newly added extension and click “Get started”.

You will be redirect to a page asking you what kind of node you have. Select “Local node”.

Joule will request additional permissions to read and change data on localhost. Click “Allow”.

Step 3:

You will now be redirected to a page where you need to type in the URL for your node (the prefilled default is https://localhost:8080). Change the value to https://umbrel.local:8080 and click “Connect”:

After clicking “Allow” on the next Chrome prompt, you will probably still get an error message saying that it failed to connect to the node.

In that case, click on “clicking this link” in the error message. A new tab will open with a Chrome security warning. Click on “Advanced” and ignore the certificate warning.

You should now see an error message like this:

This is actually a good sign. You can now go back to the original tab, click “Connect” once more and you will be able to proceed!

You should now see a page asking you to upload your macaroon files. These are used to verify that Joule has the right permissions to perform actions on your Umbrel node.

Getting these files from Umbrel is slightly tricky; you will have to use the command line to download them through SSH.

Open your computer’s terminal application.

If you’re on Mac or Linux, there’s a built-in command line tool in your terminal called SCP that makes this relatively easy.

We’ll start with the admin.macaroon file. Open the terminal app and run the following command to download the file from your Umbrel node to your Downloads folder (assuming that you’re using a Mac).

scp umbrel@umbrel.local:/home/umbrel/umbrel/lnd/data/chain/bitcoin/mainnet/admin.macaroon ~/Downloads/admin.macaroon

You will be asked for a password. This is the same password that you use to log in to your Umbrel node (the default is moneyprintergobrrr). Note that the terminal will not give you any feedback when you type in your password (so it might look as if you’re not really typing), but don’t worry, just type it as usual and hit enter.

After that, you should see a percentage progress while the file gets downloaded to your computer:

There it is!

Now that we have the file, let’s repeat the same process for the readonly.macaroon file:

scp umbrel@umbrel.local:/home/umbrel/umbrel/lnd/data/chain/bitcoin/mainnet/readonly.macaroon ~/Downloads/readonly.macaroon

You should now have both files downloaded to your computer.

Now head back to the extension and drag and drop both files to their placeholders and click “Continue”:

Boom! You should now see your node; all that’s left now is to confirm it. You will also be asked to create a new password to log in to your Joule account.

That’s it, you are now ready to start using your Umbrel node through Joule! 🎉

3 Things Web Developers Should Know When Building Electron Apps

Wed, 20 May 2020 00:00:00 GMT

Before I started working on Codespace, I had never really built anything in Electron. The only thing I knew was that apps like Slack and Notion were using it to create cross-platform desktop apps, and that everyone on Hacker News hated it because it consumes a lot of RAM. 🤷‍♀️

Even though I’ve built apps on the web for 10 years, it was quite a journey discovering all the quirks of Electron. Here are 3 small things I learned that can hopefully help out someone who’s just getting started:

1. Quitting logic is not trivial

Quitting an app is easy right? Surely there’s just some built-in behaviour that handles all of that for us? Wrong. Although you might not think about it as a user, when you start developing native apps, you realise that there’s often no “one-size-fits-all” for how and when apps should quit – it all depends on their use case.

For starters, the default behaviour is different based on what OS you’re using. On Windows and Linux, users have been taught that “closing the window also quits the app”. On macOS however, that is not the case: clicking the red traffic light button merely closes the window, but the app itself usually stays in the dock and keeps running in the background until you actively choose to quit it.

The difference is also not just based on the user’s OS, it also varies across apps themselves. Most apps are happy with the default OS behaviour, but some applications like 1Password will quit as soon as you close the window for security reasons. More commonly, there are cases where you want to make it appear as if the app has been quit, but in reality you’re simply hiding the dock icon while the app keeps running in the background. This is typically the case for apps that appear in your menu bar as soon as you turn on your computer.

Some apps like Google Chrome go even further and ask you to hold down cmd + Q to quit.

So to sum it up – think about how and when your app should quit. To help you out, here are some snippets of logic that you can use in your own app:

// Hide window instead of quitting when closing it:

win = new BrowserWindow({ width: 500, height: 500 })

win.on('close', e => {
  e.preventDefault() // Prevents quit
  win.hide()
})

// Quit app on macOS ONLY if using command + Q or some other force quit option:

win = new BrowserWindow({ width: 500, height: 500 })

let forceQuit = false

// Triggered before close event, i.e. when pressing command + Q
app.on('before-quit', () => {
  forceQuit = true
})

win.on('close', e => {
  if (!forceQuit && process.platform === 'darwin') { // "darwin" is macOS
    e.preventDefault() // Prevents quit
    win.hide()
  }

  // Let the app quit normally...
})

2. Write thrice, run everywhere

One of the expectations developers might initially have when building apps with Electron is that you can happily hack around on your Mac, make sure it runs there, and then ship the code assuming that it will work just as well on Windows and Linux.

Woah, not so fast, cowboy! Again, there are some core differences in how the OS works, and you definitely need to test your app extensively on all three platforms if you’re going to market it as a cross-platform app. We’ve already talked about quitting logic, but here are some other examples of often overlooked quirks that you need to think about:

Short commands are different. Mac users are used to ”⌘ + key” to trigger an action within an app, whereas Linux and Windows users use “CTRL + key”.
Scrollbar visibility. If you’re a web designer, you probably already know the pain of shipping a website that looks great on your Mac, only to find that, when you open it on Windows, there are these horrible-looking scrollbars everywhere. Electron apps are no different, so you will probably want to style your scrollbars.
Differences in layouts and menus. Most well-designed apps will use so-called “frameless” styling, to avoid having an ugly grey bar on top of their app’s window. This is trivial to achieve in Electron, using BrowserWindow({ frame: false }), however, you’ll most likely want to tweak your layout slightly for each platform after setting it. Below is an example of how I had to add some top padding – but only to the macOS version of Codespace – in order to take into account the area occupied by the traffic lights:

This is of course not everything, there are also differences when it comes to installation, auto-updates, emoji support… etc. In short, you need to test your app on all three platforms. I personally found that paying for something like Parallels Desktop was probably the best investment I ever made while building my app. There are also free alternatives like VirtualBox, but from what I understand, there’s a considerable difference in performance, which could affect your developer happiness.

3. You don’t need the App Store

As web developers, we’re used to deploying our sites to a server and have them live instantly, but as we know, native apps work a bit differently. One of the dilemmas I faced when Codespace was getting close to launching was whether to use the Mac App Store or not. After all, it’s an extra distribution channel that might bring in some more customers, but I was also nervous about unwarranted app rejections and the various stories of Electron apps being booted from the store. On top of that, 30% is a pretty hefty fee for what Apple is providing if you ask me.

In the end, I decided to distribute the app myself, and I haven’t regretted it one bit. Sure, it’s a little bit of extra work setting up your own payment and licensing system, but if you’re going cross-platform, you will have to do that anyway. It also pushed me to take 100% control of the marketing of the app, and I discovered that spending some extra time creating a nice-looking landing page is more likely to yield great results than just uploading some screenshots to the store.

In short, if your app is cross-platform, I don’t see any great benefit to using the App Store as your main distribution channel. Skipping it also frees you from going through a potentially long review process every time you push an update to your app. You will however still need to pay for an Apple Developer Account in order to sign and notarise your app, otherwise it won’t run on anyone else’s Mac.

Announcing SweetAlert 2.0 🎉

Thu, 07 Sep 2017 00:00:00 GMT

SweetAlert is a little side project that I released in 2014 in order to help developers implement dialogs that don’t suck in their web apps. When I first released it, I had no expectations whatsoever, and frankly did it mostly to spice up my boring GitHub profile.

The famous animation that caught a lot of people’s attention

Three years and over 16 000 GitHub stars later, SweetAlert is no longer a little pet project, but has grown to become an indispensable tool for thousands of websites all around the world.

Things have changed dramatically in the JavaScript ecosystem since its first release however. Bower and templating languages no longer rule the world, and ES2015/ES2016/ES2017 is becoming mainstream. A major revamp of the library is long overdue.

With SweetAlert 2.0, I hope that the library will continue to be useful for another 3 years. Not only has the library been rewritten from the ground up using TypeScript and PostCSS, but it also comes with some awesome new functionality.

So what’s new?

By far the most requested feature in the original library was the the ability to cutomise SweetAlerts with extra buttons and content. For this, I looked into the most common alerts used on major websites like Facebook and Pinterest for inspiration.

Rather than bloating the standard library with lots of app-specific options, SweetAlert 2.0 can render all of these thanks to its new content parameter, which lets you pass in a custom DOM node. This DOM node can be designed either from scratch in pure JavaScript, or with the help of one of your favourite rendering libraries, like React or Vue.

// A React component...
const List = () => (
  <ul>
    <li>Item 1</li>
    <li>Item 2</li>
  </ul>
)

// Render it as a DOM node...
const wrapper = document.createElement()
ReactDOM.render(<List />, wrapper)
const listEl = wrapper.firstChild

// And pass the DOM node to SweetAlert!
swal({
  text: "Here's a list:",
  content: listEl,
})

SweetAlert 2.0 is also completely promise-based. This means you can get some seriously cool flows, especially if you combine it with async+await.

const deleteFile = async () => {
  // Wait for the user to press a button...
  const shouldDelete = await swal("Delete file?", "Are you sure that you want to delete this file?", "warning");

  if (shouldDelete) {
    // Code to actually delete file goes here
    swal("Poof!", "Your file has been deleted!", "success");
  }
}

Overall, the API has been revamped to be as simple as possible and gracefully upgradeable. Take a look at this example of how you can change the number of buttons in an alert:

// No buttons:
swal({
  text: "This modal has no buttons!",
  buttons: false,
});

// 1 button:
swal({
  text: "Here’s a modal with one button!",
  button: "Click me!",
});

// 2 buttons:
swal({
  text: "Two buttons…",
  buttons: ["Cancel", "Click me!"],
});

// 3 buttons:
swal({
  text: "Even three buttons, each with their own promise value!",
  buttons: {
    cancel: "Cancel",
    confirm: "Click me!",
    hello: "Say hello!",
  },
});

There’s a lot more stuff packed in, but rather than go through it all here, I suggest you head over to the shiny new SweetAlert website. A big thank you to everyone who’s helped contribute to the library! Here’s to the next three years! 🍻