Serving displays since 1984

hi frens me again :3

just a quick PSA for anyone running newer Intel CPUs, their latest microcode update your system won't boot past the bootloader if you updated to the latest microcode version. (source)

for now the easiest work around is to add a package exclusion to your system so you can keep updating without breaking anything. (thank u limine and snapper i love you)

For my fellow arch users:

Open /etc/pacman.conf and add in IgnorePkg = intel-ucode under the [options] section like this:

If you already have any exclusions, just add it in after with a space separating them.

Then run sudo pacman -Syu and you should see it being excluded fom your update list. You should remove it later once everything is all good but this is a bandaid solution.

there's also another annoyance where you see posts that do point out the material conditions for why adoption of linux on desktop computers is so low (my program doesn't work -> OS is not adopted by users -> people writing programs don't make a linux version because of seemingly too much effort for the number of users) and they're true, but also they attract a certain population of users which treat this as an invitation to rant on the linux community and the obnoxiousness, and how some linux user dared to suggest to switch linux at them. and what now, do I reblog this with the comment of "yes I am one of the good ones" or similar. am I supposed to provide eternal tech support without complaining because if I complain once I will be labelled as the obnoxious linux user and this will reflect on the wider linux community.

> realize every screen displays color slightly differently

> realize every camera captures color a little differently

> realize every format and image editor translates color

> realize every printer deposits ink differently

> realize every kind of paper accepts ink differently

> realize colors look completely different under different lighting conditions

> ok I'm going to do everything greyscale now

> black density changes as ink cartridge depletes and depending on viscosity after multiple prints

> "what color white are you using"

I'm essentially just using jumps as a workaround for not having nested functions with dynamic binding, or match arms with guards. Equivalent Rust would look something like this:

(Unrelated, I've changed themes between these screenshots)

I could inline these blocks, sure, but I want to associate them with names to clarify my intentions. "Why are we advancing the input source? Because we read whitespace." "Why are we advancing to EOL (or EOF)? Because we're in a comment."

I could ditch the switch altogether, but I want to optimize for inputs that use mostly ASCII whitespace, in exchange for slightly slower multibyte handling.

I'm still prototyping right now, though, so if you can get something better and prove it with godbolt, I'm all ears.

#it's legible enough i suppose i just worry it'd be hard for a compiler to optimize#it is more common to do this kinda thing in c++/c but still

Harder for the compiler to optimize how? Unless you mean the way I'm doing byte-by-byte string comparison, or how I'm calling these other helper functions (they're small and easy to inline + hoist).