break.build.repeat

Moving from Ubuntu to Omarchy

Thu, 08 Oct 2026 00:00:00 GMT

Ubuntu was working fine. Nothing was broken, nothing was annoying me, and I had no good reason to change it.

I did it anyway, out of curiosity. I’d been hearing about Omarchy, an opinionated Arch-based setup built around the Hyprland tiling window manager, and I wanted to see what it felt like. This is what the first stretch of using it has been like, written while I’m still fumbling for the right keys.

Why a second drive

I didn’t want to wipe a working machine on a whim, so I put a spare SATA SSD in the PC and installed Omarchy on that. Ubuntu stayed untouched on its own drive.

That turned out to be the right call. If I got stuck, or hated it, I could pick the other drive in the boot menu and be back where I started. It took the pressure off. I was trying something out, not betting my main machine on it.

Moving everything over

This was the part I expected to be painful, and it wasn’t. Getting my stuff from one install to the other was easy, much easier than I’d braced for.

I moved everything. I had a drive big enough to hold all my data, so there was no deciding what to keep and what to leave behind.

Having both systems on separate drives in the same machine helped a lot. Nothing felt like it was gone.

The experience

I like it. I’m still figuring out the keybindings, and my hands keep reaching for the Ubuntu way of doing things, but the overall experience has won me over.

A tiling window manager changes how you think about windows. Instead of dragging things around and stacking them, you tell the system what you want open and it arranges them. It’s built around the keyboard, which is exactly why my muscle memory is currently useless.

The thing I notice most is the speed. Ubuntu was never slow, but Omarchy is so quick that it makes Ubuntu feel slower in hindsight.

The real reason

If I’m honest, curiosity was the starting point, but the reason I’m sticking with it is that it forces me to get better at Linux.

Ubuntu is forgiving. Most things just work, and when they don’t, there’s a button or a Software Center entry that sorts it out. That’s a good thing, but it also means I’ve been able to use Linux for years without properly understanding it. Omarchy puts me closer to the machine. Config lives in files I have to read, and when something isn’t right I have to work out why.

I work with systems for a living and run a homelab, so that discomfort is the point.

What broke

Sound. I had no working audio for ages. It turned out to be three separate problems stacked on top of each other, so fixing any one of them still left me with silence.

1. The wrong default output. PipeWire had its default set to “USB Audio S/PDIF Output”, a digital output with nothing connected to it. Everything I played went there, silently.

2. Muted below PipeWire. The sound card’s PCM 0 and PCM 1 playback outputs were switched off in the ALSA hardware mixer. That layer sits underneath PipeWire, so the normal volume and mute controls never show it. I turned them back on at 69%.

3. A plug that wasn’t properly in. The card reported both the speaker and headphone jacks as “not available”. I tried different jacks, direct ALSA test tones and the monitor’s audio, and heard nothing from any of it. The cause was that the plug wasn’t pushed in firmly after I’d briefly unplugged it. Once I seated it properly, the card detected the headphones on the Headphone output. My earlier test beeps had been going to the Speaker output, which is why I never heard them.

The lesson is that audio on Linux is a stack, and each layer can fail independently: the physical jack, the hardware mixer, then PipeWire’s choice of output. A fault in a lower layer won’t show up in the layers above it. Next time I’ll work from the bottom up and check each layer before assuming the problem is in the one I’m looking at.

It cost me a lot of time, but I understand how the pieces fit together far better than I did.

Sound was the big one, but it wasn’t the only thing.

Per-app settings and tiny fonts. Almost everything is customisable on a per-app basis, which is great until you’re the one who has to do it. Text was small at first, and what looked fine in one app was too small in the next. Some apps didn’t load the way I wanted, and fixing each one meant its own bit of fiddling. The flexibility is real, and so is the effort of getting it all how I like it.

Keybindings. Beyond my hands reaching for the Ubuntu shortcuts, I ran into bindings that didn’t do what I expected. In a setup built around the keyboard, a wrong binding stops you in your tracks.

Dual screens. I use two monitors, and they needed different display settings. Each one is configured separately, so the fix for one screen doesn’t carry over to the other.

The apps I fiddled with most were Visual Studio Code, Blender and my media app.

I’ll add to this section as I find more.

What other people ran into

Experiences vary a lot. One blogger found hardware support on a ThinkPad stellar, with a working system minutes after the installer. Others hit trouble. None of the following happened to me, but they’re worth knowing about before you try this yourself:

NVIDIA on first boot. A GitHub issue describes Hyprland stuck in a loop after install on an RTX 4060 Ti, fixed by installing the NVIDIA drivers from a TTY.
Arch underneath. Omarchy is Arch with opinionated defaults, so you get the rolling release and its sharp edges too. The same blogger thinks Ubuntu Desktop or Fedora KDE would take less tinkering.
Gaming. Compatibility depends on the game, anti-cheat and launcher, so keep a fallback if that matters to you.

These are individual reports, not proper testing, so treat them as anecdote. The sensible advice is what I did by accident: try it on a spare drive first, and check audio and displays before you commit.

Where I am now

For now I’m booting Omarchy. Ubuntu is still on its own drive if I need it.

I’m not done learning it, and I’ll keep updating this post as I experiment. But so far I’m enjoying it, and it’s a good reminder that the best way to learn something is to make yourself live in it.

Really understanding IPv4 and IPv6

Mon, 05 Oct 2026 00:00:00 GMT

I’ve typed ipconfig thousands of times. I look at the IP address, ignore the two lines underneath it, and get on with my day.

If you’d asked me last week what a subnet was, I’d have given you a reasonable answer. A range of addresses. A chunk of a network. What I couldn’t have told you is what it’s for. What does my PC do with that mask? I had the definition and none of the understanding, which is an uncomfortable thing to notice when networking is part of your job.

So I sat down with my own machine and worked through it from the top. This is what I found, along with the things I got wrong on the way.

What my machine told me

Ethernet adapter Ethernet 3:

   IPv4 Address. . . . . . . . . . . : 192.168.1.181
   Subnet Mask . . . . . . . . . . . : 255.255.255.0
   Default Gateway . . . . . . . . . : 192.168.1.1

192.168.1.181 is my PC. 192.168.1.1 is my router, which Windows calls the default gateway. The mask is the line I’d been ignoring for years, and it turns out to be the interesting one.

The mask answers one question

Every time my PC sends anything, it has to decide: is the destination on my network, or somewhere else? If it’s a neighbour, it delivers directly. If it isn’t, it gives the packet to the router and lets the router worry about it.

The mask is how it decides. Stack the two on top of each other:

Address  192 . 168 .  1  . 181
Mask     255 . 255 . 255 .  0

Where the mask says 255, that number has to match for someone to be a neighbour. Where it says 0, anything goes. So for me, anything starting 192.168.1. is next door, and everything else goes to the router.

Destination	Starts `192.168.1.`?	My PC…
`192.168.1.44`	Yes	delivers it directly
`192.168.2.44`	No	hands it to the gateway
`8.8.8.8`	No	hands it to the gateway

The bit that surprised me is that the last two rows are the same. My PC has no idea 8.8.8.8 is Google, out on the internet, while 192.168.2.44 is a private address. It does one comparison and that’s the end of its involvement.

It also explains something about my own setup. My homelab isn’t on that 192.168.1. network. It sits behind its own OPNsense firewall, which is plugged into my router for now while I test it, and it has its own subnets split across VLANs. The house and the homelab aren’t neighbours, so nothing gets from one side to the other without going through that firewall. That makes it the one place I get to decide what’s allowed across. The VLANs are up and running, though there’s still a lot of work to do on them. At least now I understand why the design works.

So what’s a /24?

Each of those four numbers is 8 bits, which is why none of them goes above 255. Four numbers, 32 bits in total.

The mask is a single line drawn through those 32 bits. Everything left of the line is the network, and everything right of it is the individual device. A 255 means all 8 bits of that number are on the network side. I’ve got three of those, 3 × 8 is 24, and that’s the whole story behind /24. It’s the same mask as 255.255.255.0, written in a way that’s quicker to type. The slash style is called CIDR notation.

It counts locked bits, not locked numbers. That distinction didn’t seem important until about ten minutes later.

The picture that made it click for me was a postal address. The network part is the street, the device part is the house number, and the mask tells you where the street name stops.

Have a play with it. Drag the slider and watch what happens to the line, the mask and the address count:

When the line lands in the middle of a number

My PC has a second network adapter that Hyper-V created, and it ruined my nice simple rule:

   IPv4 Address. . . . . . . . . . . : 172.24.160.1
   Subnet Mask . . . . . . . . . . . : 255.255.240.0

Not 255, not 0. You can’t say “this number must match” or “this number is free” any more, and this is the point where I had to stop avoiding binary.

Each bit is a switch with a fixed value. Add up the ones that are on:

128  64  32  16   8   4   2   1
 1   1   1   1    0   0   0   0     = 240

128 + 64 + 32 + 16 is 240. The first four switches are on, so in that third number the first four bits belong to the network and the last four belong to the device. Two full numbers plus four bits: 8 + 8 + 4, which is /20.

It leads to something that looks wrong at first. 172.24.170.5 is a neighbour of 172.24.160.1. 160 is 1010 0000 and 170 is 1010 1010. The first four bits match, and those are the only ones the mask cares about.

Try the Hyper-V preset in the calculator above and you’ll see the line sitting in the middle of the third number.

How many devices fit?

Only the free bits matter here, and every extra free bit doubles the count.

CIDR	Free bits	Addresses
/24	8	256
/23	9	512
/22	10	1,024
/21	11	2,048
/20	12	4,096
/16	16	65,536

You lose two from every network. The first address is the name of the network itself, and the last is the broadcast address, which means “everyone here”. So my /24 at home fits 254 devices. Azure keeps five per subnet for itself, so a /24 there gets you 251.

Move the line left and you get fewer, bigger networks. Move it right and you get more, smaller ones. As far as I can tell, that trade-off is most of what subnet design is.

The things I got wrong

All three of these were mine.

Counting from zero. I confidently said the highest number you can make with four bits was 16. It’s 15. Sixteen is how many values there are, because zero counts as one of them. Then I decided three bits went from 0 to 8. They go from 0 to 7.

Thinking a bigger slash means a bigger network. I had it the wrong way round. A bigger number after the slash locks more bits, which leaves fewer free ones, so the network is smaller. A /25 is half the size of a /24.

Assuming .0 and .255 are always reserved. I thought every address ending in those was off limits. That’s a habit from /24, not the rule. The reserved addresses are the first and last of the whole network, wherever those fall. In my Hyper-V /20, 172.24.160.255 and 172.24.161.0 are perfectly ordinary addresses in the middle of the range.

And then IPv6

The same ipconfig output had a few lines I’ve always scrolled straight past. I’ve swapped my real addresses for made-up ones, for reasons that’ll be obvious in a minute:

   IPv6 Address. . . . . . . . . . . : 2001:db8:a1b2:c3d4:7c1e:52a9:f03b:6d84
   Temporary IPv6 Address. . . . . . : 2001:db8:a1b2:c3d4:e9f0:41c7:2b6a:95d3
   Default Gateway . . . . . . . . . : fe80::1a2b:3cff:fe4d:5e6f%12

I knew IPv6 was written in hex. What I hadn’t appreciated was the scale: I’d assumed it was IPv4 with a couple more numbers bolted on the end. It’s 128 bits instead of 32, which is why it needs hex in the first place. Nobody wants to read sixteen dotted decimals.

The idea underneath is the same one I’d spent the evening on. One line, network on the left, device on the right. It’s nearly always a /64, so the line sits bang in the middle and you don’t need any of the binary from earlier:

2001:db8:a1b2:c3d4 : 7c1e:52a9:f03b:6d84
     network      |       device

A few things do change.

There’s no NAT. That’s the trick my router uses on IPv4, swapping each device’s private address for its own single public one on the way out. It exists because IPv4 only has about 4.3 billion addresses for the whole planet, so everything in my house has to share. A single IPv6 /64 has around 18 quintillion. Every device gets a real, public address of its own.

That fe80:: gateway address is link-local, meaning it only works on my own street. It’s how my PC talks to the router without needing a public address to do it.

And the “temporary” address is a privacy thing. Without NAT, every site I visit sees my PC’s own address. So Windows makes up a second one with a random device half, uses it for outgoing connections, and throws it away after a while. I guessed it was something to do with incognito mode, which was the right idea in the wrong place.

Hang on, is that safe?

That was my first reaction. Every device in my house has a public address?

It turns out NAT was never the thing keeping me safe. It hid my devices by accident, as a side effect of sharing one address. The actual protection is the firewall. By default a home router drops any connection that starts from outside and only lets in replies to things you asked for, and Windows Firewall sits behind that as a second layer.

An address says where you are. A firewall decides who gets to knock. Azure works the same way: you can give a VM a public IP, and a Network Security Group decides what reaches it.

What’s next

I want to see what NAT does to a packet on its way out of my house. Then DHCP, because something handed my PC that mask and I’d like to know what. After that I’m going to carve up an Azure VNet and get the subnet sizes wrong on purpose.

Three short posts a week is the plan. If I can’t explain it, I don’t know it.