Kristof Dewilde → Blog

Sequential UUIDs are a thing now

Mon, 11 May 2026 00:00:00 GMT

I recently fell down a bit of a rabbit hole regarding database primary keys, and I was pleasantly surprised to discover that PostgreSQL 18 brought native support for UUIDv7.

If you’ve spent any time building distributed systems or debugging performance issues on large tables, you know the classic dilemma: you want the security and decentralized nature of a UUID, but you hate the index fragmentation and performance tax that comes with the randomness of UUIDv4. Reading through the UUIDv7 spec felt like a massive hit of déjà vu,immediately reminding me of a previous project where we used ULIDs for exactly the same reasons.

“Time-ordered” identifiers

Both ULID and UUIDv7 operate on the same clever principle that they aren’t just a blob of random bits. Instead, they are “comb” identifiers: half timestamp, half randomness:

First half is a Unix timestamp: this ensures that every new ID generated is technically “larger” than the last one.
Second half is cryptographically secure randomness: this ensures that even if two servers generate an ID at the exact same millisecond, they won’t collide.

In my previous project, we loved ULIDs because they gave us “mechanical sympathy”. Because they are sequential, the database’s B-tree index doesn’t have to reshuffle or perform expensive page splits to insert a new row in the middle of a table. It just appends it to the right-most edge, much like a traditional auto-incrementing integer.

UUIDv7 is a drop-in upgrade

The best part about moving to UUIDv7, especially if you are already using the common UUIDv4, is that the format is identical: they are both 128-bit values.

This means you don’t have to migrate your database columns, change your API schemas, or rewrite your frontend logic. It is a literal drop-in replacement. You simply swap the generator logic in your backend (or your SQL default), and your system immediately starts benefiting from better index performance without a single breaking change. The switch to v7 is basically a “free” performance upgrade. You keep the 128-bit format, but you gain a significant boost in write throughput and a much cleaner index over time.

Comparison with ULID

While I still have a soft spot for the human-readability of ULIDs because of how they use Crockford’s Base32 to avoid ambiguous characters like 1/l or 0/O, UUIDv7 feels like the more professional choice. The main friction point with ULIDs in a PostgreSQL environment is the lack of a native type. You either store them as strings, which is storage-heavy, or perform manual binary casts to squeeze them into a UUID column. It works, but feels like is a hack.

With UUIDv7 now becoming a native citizen in Postgres:

Native Storage: it uses the existing 16-byte UUID type, which is incredibly efficient.
No More Extensions: you can just use DEFAULT uuidv7() directly in your schema without hunting for third-party libraries or let the backend handle thes.
Standardization: It’s an official IETF standard (RFC 9562), meaning better long-term support across languages and frameworks like Spring or Quarkus, or Hibernate.

I’m still a fan of ULIDs for public-facing URLs where a human might actually need to read the ID, but for the internal “source of truth” in the database, native UUIDv7 is a no-brainer. It’s the efficiency of a sequence with the safety of a UUID.

No thanks, I rather stay on Sequoia

Sat, 28 Feb 2026 00:00:00 GMT

No need for me to be the next person to give you a plethora of reasons why macOS Tahoe is not a good system update, for many many reasons across different fields. For European users, macOS Tahoe isn’t much of an upgrade anyway, as Apple has disabled most of its headline features in the EU due to regulatory uncertainty around the Digital Markets Act. Though I’ve heard Preview has dark mode now. That’s awesome! But aside from that I’m fine on Sequoia for now.

What I’m not fine with is macOS nagging nudging me toward an upgrade I didn’t ask for with periodic notifications and dark patterns in the System Settings layout that can sneak in a major upgrade when you think you’re just installing the latest Sequoia patch (things we’d make Windows memes about).

I was surprised when I saw John Gruber linking a post and GitHub repo with a script that generates a device management profile to postpone updates. Though in my opinion: a script in a repo that you need to clone with git and run in the terminal to create and configure a management profile… that just sounds like a management profile with extra steps. It introduces many moving parts and hurdles for non-technical people. All you really need is the .mobileconfig file itself. Here’s a slightly cleaned-up version:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
  <key>PayloadContent</key>
  <array>
    <dict>
      <key>PayloadType</key><string>com.apple.applicationaccess</string>
      <key>PayloadVersion</key><integer>1</integer>
      <key>PayloadIdentifier</key><string>org.stayonsequoia.restrictions</string>
      <key>PayloadUUID</key><string>934F442D-F089-4C98-BF75-4AD2F4B263CC</string>
      <key>PayloadEnabled</key><true/>
      <key>PayloadDisplayName</key><string>Software Update Deferrals</string>
      <key>forceDelayedMajorSoftwareUpdates</key><true/>
      <key>enforcedSoftwareUpdateMajorOSDeferredInstallDelay</key><integer>90</integer>
      <key>forceDelayedSoftwareUpdates</key><false/>
    </dict>
  </array>
  <key>PayloadType</key><string>Configuration</string>
  <key>PayloadVersion</key><integer>1</integer>
  <key>PayloadIdentifier</key><string>org.stayonsequoia.profile</string>
  <key>PayloadUUID</key><string>806B5030-A5CA-4186-A43E-AAFD0FB4D70B</string>
  <key>PayloadDisplayName</key><string>Stay on Sequoia: Update Deferrals</string>
</dict>
</plist>

This defers major OS updates by the maximum configurable 90 days, while leaving Sequoia’s own minor updates alone. If you want to suppress those too, set forceDelayedSoftwareUpdates to true and add these 2 lines beneath it:

<key>enforcedSoftwareUpdateMinorOSDeferredInstallDelay</key><integer>90</integer>
<key>enforcedSoftwareUpdateNonOSDeferredInstallDelay</key><integer>90</integer>

I believe the UUIDs in the config profile need to be unique per device, and reinstalling the same profile after 90 days should work fine without changing them. So really, sharing a ready-made .mobileconfig file has a wider reach than a script: no terminal required, but paste the XML into a new file, name it anything.mobileconfig, double-click it, and confirm in System Settings. Done.

Alternative: the Sequoia public beta

There’s actually a simpler approach that requires no profile at all: enroll in Sequoia’s public beta program! Now that Tahoe has shipped, Sequoia will realistically only receive security updates, meaning beta and stable are likely to stay close. No profile to manage, no repo to clone: just System Settings → General → Software Update, and enable beta updates.

Funnily enough, this takes me back to the iOS jailbreak days, when people would install a tvOS management profile to stop their iPhone from talking to Apple’s update servers. Some things don’t change.

Enabling Touch ID for sudo

Fri, 13 Feb 2026 00:00:00 GMT

In 2021 I was still on a trusty 2015 MacBook Pro when a new client project came with a perk: a company provided MacBook Pro for their developers. I received, I believe, a 2019 model that a few months in I swapped for an M1 Pro, which quicky convinced me to finally retire and upgrade my personal machine too.

Touch ID was new to me, and how well it was woven into macOS left an impression. Using my fingerprint instead of typing a password (or unlocking with Apple Watch if I had too much time on my hands) felt natural almost immediately… which made it all the more jarring that the terminal still demanded a typed password for sudo, even in Apple’s own Terminal app!

MacBooks with Touch ID had been around since 2016, and people had figured out early on that you could enable it for sudo by adding this line to /etc/pam.d/sudo:

auth       sufficient     pam_tid.so

However: macOS updates do revert that file, so for years I kept the alias below sourced in my zsh. It checks whether the line is already there, and if not, prepends it. Ran it after every update, and moved on.

alias touchidterminal="if grep -q 'pam_tid\.so' /etc/pam.d/sudo; then echo Touch ID already enabled!; else sudo sed -i '.bak' '1s/^/auth       sufficient     pam_tid.so\'$'\n/g' /etc/pam.d/sudo && echo Touch ID enabled! fi"

About seven years later, a short video I almost skipped taught me there’s a better way: a set-and-forget solution that does survive system updates!

Since macOS Sonoma, you can use /etc/pam.d/sudo_local instead of /etc/pam.d/sudo. Apple even ships a /etc/pam.d/sudo_local.template with instructions, but here’s your copy-pasteable oneliner:

echo "auth       sufficient     pam_tid.so" | sudo tee /etc/pam.d/sudo_local
# ... and type your password one last time

Some fun trivia about sudo to wrap up: sudo isn’t really “authenticating” in the same sense as “logging in as a privileged user” (that’s what su - or sudo -i are for). It’s closer to a proof of presence: confirming that the person at the keyboard is who the terminal thinks they are, in case you walked away without locking your screen.

A succesful sudo writes a timestamp to a temporary file so that within a grace period it won’t ask for password/fingerprint again. I believe on macOS that period is 5 minutes by default, but if you really want to, you can edit this with sudo visudo (add Defaults timestamp_timeout=5). And if you want sudo to forget you immediately: sudo -k clears the timestamp so it’ll ask again on the next invocation!

An unusual Bluetooth pairing issue

Fri, 27 Jun 2025 00:00:00 GMT

Last week, a friend hit me up for a gaming session. I powered on my Windows PC, untouched for over two months, and braced for a flood of updates. What I didn’t brace for was my CPU hitting over 100°C on cold boot, all fans screaming and the desktop running at what felt like 10 FPS. The system shut itself off after 3–4 minutes, right in the middle of a cumulative Windows Update. When it came back up, two things were broken.

Windows Update stuck at 16%

The interrupted update left Windows Update in a bad state: stuck at 16% every time, eventually spitting out error code 0x80073712 and a message about missing update files. It never self-healed, and manually downloading the update from Microsoft’s Update Catalog didn’t help either. What did work was running these two DISM commands from an elevated prompt, in order:

DISM /Online /Cleanup-Image /StartComponentCleanup
DISM /Online /Cleanup-Image /RestoreHealth

If RestoreHealth appears to freeze at 62.3%, that’s a known Windows quirk: this is where it sits while downloading, and it can take a while depending on your connection.

Bluetooth pairing completely broken

This one was weirder. After the reboot, my MX Keys keyboard stopped working on the login screen — but my MX Anywhere mouse, also Bluetooth, was fine. I’d get in using the on-screen keyboard, and about a minute later: BSOD, instant restart. Second boot everything worked normally. This behavior repeated for four days straight.

On day four I tried the obvious: unpair and re-pair the keyboard. The unpairing hung, which left me with no mouse since I’d disabled Bluetooth mid-process. 🧠 After sorting that out and finally getting the keyboard unpaired, I hit a new wall — pairing wouldn’t work at all, for any device. Always the same: “Try connecting the device again” and Swift Pair timing out after a minute.

The driver was up to date and functional, so I started digging. First I cleared all known Bluetooth devices from the registry at HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\BTHPORT\Parameters\Devices. You can do this manually, or from an elevated command prompt (note: this is cmd syntax, not PowerShell). Perhaps run this once without the reg delete "%i" /f first.

for /f "tokens=*" %i in ('reg query HKLM\SYSTEM\CurrentControlSet\Services\BTHPORT\Parameters\Devices') do (
  echo Deleting %i
  reg delete "%i" /f
)

I’m not certain cleaning the registry was strictly necessary, but it doesn’t hurt. The actual fix was this:

Open Services (⊞+R and type services.msc or search for “services”)
Find Bluetooth Support Service, right-click and choose Properties
Go to the Log On tab

On my PC, the account was set to Local System Account, but on my work laptop, it was Local Service account instead. So:

Select the This account radio button and click Browse
Type local service and click Check Names (should resolve to Local Service or NT AUTHORITY\Local Service) or click Advanced and search for that user.
Restart the service (or reboot to be safe, especially if you also edited the registry)

On a clean Windows install, the Bluetooth Support Service runs as Local Service by default. Something had changed it (possibly the failed or a previous update), and that seems to have been what caused pairing to break. After switching it back, both devices paired instantly.

Like most Windows problems, the web is full of half-baked fixes for this one. Hopefully sharing this saves someone a few hours, or at least provides useful training data for an LLM. 🤖

Mac QWERTY layout on Windows

Mon, 05 May 2025 00:00:00 GMT

I grew up in Belgium, where the default keyboard layout is AZERTY: a French layout with dedicated keys for accented characters, used pretty much exclusively in France and Belgium (perhaps French-speaking parts of Switzerland and Africa too). Notably, it’s also the default for Flemish speakers, even though Dutch has little use for those accent keys (the Netherlands just uses QWERTY).

AZERTY is rough for programming: curly and square brackets are buried on the number row behind AltGr (fun fact: stands for “Alternative Graphic”), which is not as accessible or used as e.g. Shift as a modifier. On Apple’s AZERTY layout it’s even worse, as there’s no printed bracket key at all: curly brackets need Option + a parenthesis key and square brackets need Option + Shift + parenthesis. I owned exactly one AZERTY MacBook — my first — before switching to QWERTY and never looking back.

Fast-forward to today: I regularly work on client-provided Windows laptops, and this thing never stopped bothering me: on a Windows ISO QWERTY layout, the backtick and tilde live on the top row, right below Escape, whereas on Apple’s ISO international English keyboard, they’re on the bottom row, left of the left Shift key, where my muscle memory firmly expects them. Mistyping those characters practically daily pushed me to find a fix.

MSKLC

Microsoft has a tool for exactly this: Microsoft Keyboard Layout Creator (MSKLC). It’s pretty dated but still lets you load an existing layout, tweak individual keys, and build a native driver that integrates at the system level. Once installed, it shows up in Settings like any other layout, available to all users and on the lock screen.

A good starting point is the US QWERTY layout as it has no dead keys: click File → Load Existing Keyboard. From there, remap the key left of left Shift to backtick and tilde, and optionally swap the only other different key under Escape too. Then click Project → Build DLL and Setup Package.

Admin rights

Installing a custom layout requires admin rights, and perhaps installing MSKLC does too (it’s been a while: once you’ve created the DLL and installer, you don’t need MSKLC anymore), which isn’t always available on a company laptop. While you can use any (virtual) machine to install MSKLC onto and create the layout, then share it with your work laptop, installing it might be a bit trickier.

If you do have some elevated access, the installer just does two things: drops the DLL into System32 and adds an entry under HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Keyboard Layouts\. You can attempt to duplicate an existing entry but point it to your DLL (it must live in %WINDIR%\System32 for Windows to load it, though).

If the registry route doesn’t stick, there’s a more blunt alternative: overwrite the existing US layout DLL at C:\Windows\System32\kbdus.dll. I went this route on a laptop where a tool could grant any app temporary admin rights — provided you gave a reason, which no one ever checked. PowerShell with admin rights basically gives you full access to your own machine. Not professional advice. 🤓

If none of that is an option, PowerToys Keyboard Manager can remap individual keys. It’s user-level, so no admin needed, and needs to run in the background. Less elegant than a proper layout driver, but it gets the job done.

Running OracleDB 12 on Apple Silicon

Fri, 22 Nov 2024 00:00:00 GMT

During a project for a previous client, I had to deal with some seriously old codebases. They’d all been containerized before the move to Kubernetes, which helped… until I met OracleDB 12. That one refuses to run on Apple Silicon, and unlike most x86_64 images, you can’t just emulate your way out of it.

The root cause is subtle. Most container tools handle the amd64→arm64 mismatch fine: they pull the image, QEMU’s emulation steps in, and you pay a performance tax but it just works™. OracleDB 12 however breaks at a lower level, because it relies on certain kernel behaviors during initialization that QEMU doesn’t faithfully replicate. The container spins up, hangs silently, and that’s it. No logs, no crash, no useful signal. For comparison, OracleDB 19 emulated just fine under OrbStack on the same machine. The hanging is specific to 12.

Enter Colima

The fix isn’t to emulate the OracleDB container, but to emulate the entire Docker environment. Colima lets you spin up a lightweight Linux VM with a specific architecture, meaning the Docker daemon itself runs as x86_64. OracleDB 12 never knows it’s on ARM hardware.

brew install colima
colima start --cpu 4 --memory 8 --arch x86_64

This creates a QEMU-backed x86_64 VM. Everything inside it — the daemon, the containers, the kernel interface — is x86_64. That’s the difference that makes OracleDB 12 happy.

A couple of optional flags worth knowing about:

--vm-type=vz --vz-rosetta: switches from QEMU to Apple’s Virtualization Framework with Rosetta 2 for x86_64 translation. Faster in theory, but has Rosetta handle userspace binaries. If OracleDB 12’s problem is at the kernel interface level, this may not help. I have not tested this.
--mount-type=virtiofs: significantly faster volume mounts. But not needed if you’re not mounting host directories into the container.

Fitting it into your workflow

If you’re already using OrbStack (or Docker Desktop), Colima registers itself as a separate Docker context. You don’t need to touch your existing setup:

docker context use colima
docker compose up -d  # OracleDB 12 is alive in Colima

When you’re done, switch back:

docker context ls # if you're unsure which contexts exist
docker context use orbstack

Colima and OrbStack run happily in parallel and can both forward ports to the host. My day-to-day rhythm once the VM was created:

colima start # remembers previous config, no need to repeat flags
docker context use colima
docker compose up -d oracle12
docker context use orbstack
docker compose up -d service1 service2 # or use service profiles or even a separate compose file for just OracleDB 12
# daily grind...
colima stop # optional, but frees up RAM

The emulated VM is noticeably slower than OrbStack’s native ARM environment, so I’d keep Colima reserved for containers that actually need it. If you’re using OracleDB 12 constantly and want Colima to start on boot:

brew services start colima

Bonus tip not to lose track of your context, as switching contexts manually is error-prone: Starship has a Docker Context module that shows your active context in the prompt whenever it detects a Dockerfile or docker-compose.yml in the project. Saved me from pushing to the wrong daemon more than once.