💾 Archived View for pixeldreams.tokyo › gemlog › openbsd-cons.gmi captured on 2023-06-16 at 16:11:38. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2023-01-29)
-=-=-=-=-=-=-
23 june, 2022
i've been running OpenBSD on my main computer and living in it for some time now, and i can confidently say that it has overall been the best experience i've had with any operating system.
openbsd has its own way of doing things that can take a little time to learn in the beginning, but after that point, the entire system is intuitive, consistent, and stable.
the setup procedure is much easier than many hands-on linux distros, like void or debian, and many things that have consistently been frustrating to configure on linux and freebsd are in contrast very easy in openbsd.
this includes the sound system, hibernation, full-disk encryption, auto-login, the X server, the firewall, and network interfaces (i have a very customized network environment)
there are however a few things that have bothered me since switching, some of which won't apply to everyone, but i've been asked about my experience before and i think it's important to be honest about it.
precicely, as a japanese speaker, the lack of mozc as an input method hurts. the best i have right now is anthy, which can be infuriating to use. it's hard to explain this to a foreign audience, but i'll try.
there are two details about japanese that are important here. first is that we don't use spaces to separate words. the other is that, on a US keyboard we type japanese phonetically and let a program convert it for us.
because japanese has no spaces, the program has to guess where the boundaries are between words. however for every set of sounds we type, there can be dozens of possible character combinations.
while modern input methods like mozc will sort candidates in order of how common they are, anthy does not, and it can completely alter your sentence because of this, recognizing words where there are none, and converting to obscure characters.
i often have to go back to edit what i typed because it wasn't converted correctly, which takes time and energy. this can be a total deal-breaker for many japanese users.
every OS has its own favorite filesystem. for example, linux seems to prefer ext4 generally, mac likes hfs+, and openbsd likes ffs (that's *fast file system* mind you~)
there are a few filesystems that are supported on most platforms, like FAT. however, many people don't realize that FAT is not implemented the same everywhere. in particular, FAT on windows and linux accepts unicode filenames, while on freebsd and openbsd it does not. again, this is a problem when living in a country that uses a non-ascii alphabet.
i'm not sure what the details are. perhaps the BSDs are faithfully following the specification, while linux decided to expand it. this has happened in other areas and wouldn't surprise me, but i'm not sure in this case because i haven't researched it more.
at any rate, right now the best solution i've found is using NTFS for interoperability, which seems crazy to me.
i've been trying to sync the monero chain for a few weeks now. the reason it's taking so long is that, every time i run monerod, it makes my computer usuably slow.
worse, it doesn't fully recover afterwards. for example, the trackpad stops working (but the red thinkpad dot does). i usually restart X.
i've tried starting the first process with nice to give it low priority, but it hasn't made a noticeable difference. i don't understand why it isn't possible to limit how much it consumes. perhaps i'm missing something.
i've had a peculiar bug with vmd that i haven't tested enough to make any conclusions, but here's what's happening. i can start a linux vm and connect it to the network without issue (it can ping anywhere just fine).
however, dns doesn't resolve, kind of. if i run nslookup, i can see the first record (so it is responding), but not what comes after. nslookup then waits until it times out. apps see this and think it didn't resolve at all.
i've run some packet captures to have a closer look. on the host, i can see all of the dns responses going to the vm - everything looks normal. i don't understand why the vm sees the first response but nothing else.
this happens on alpine, arch, and debian. i've tried changing the MTU and connecting the VM directly to a bridge interface, but to no avail. there are a few more things i can try, but this one has really got me for now.