nina

3d video games have looked good since at least the mid-late 90s and trying to chase photorealism instead of stylization and working with limitations is stupid and the latter is always strictly better because it at least shows that you have your own idea of aesthetic and art

heated argument topic encountered in a random place this morning: is or isn't chimera linux gay

hm my mug has chipped

hot take: dbus is mostly just kinda okay and not some kind of terrible evil thing that must be eliminated

sure it's a bit janky and the reference libdbus library to work with it is kinda ass (better ones exist now) but given when it was created it's not unusual and also it's not some kind of massive blocker that would warrant total replacement

i'm fairly convinced that 95% of dbus hate mostly stems from the session bus formerly being launched with desktop, noone really understanding what dbus-launch and dbus-run-session really do, and the subsequent confusion about "why don't my bus-using apps work from another tty and/or from a clean terminal with fresh env vars" because abstract sockets are such a niche functionality and there used to be no real session tracking

i have a feeling that everyone who is arguing about LLMs in the sense of stuff like productivity, quality of the output, performance or functionality of generated code, largely even licensing or whatnot is kinda missing the point

even if LLMs generated the best code in the world, i would not be using them

even if LLMs gave me the biggest ever productivity boost i would not be using them

even if the output was clean copyright-wise and fully original, i would still not be using them

i can't consciously support a worldwide slop machine that helps and finances the rise of fascism, that helps further oppression, that helps a bunch of billionaires control public opinion, that drives society-wide psychosis with far-reaching consequences, that attempts to strip all joy from activities people like while using that to make the rich even richer, and that's not even getting to environmental stuff or whatever

i'm getting left behind you say

well fuck your industry and fuck you

we know that two nibbles make a bite but where does a chomp come in

psa for anyone using qt6 with llvm 22 and libc++

so if you try to build qt6 (any version) with clang22 and libcxx, you will notice the tests tst_collections and tst_qmap failing

the code that is failing specifically is something like

```
QMultiMap qm;
qm.insert(1, val1);
qm.insert(1, val2);
assert(qm.value(1) == val2); // assume .value(key) always returns most recently inserted value, but it does not in practice
```

the reason for this is that QMultiMap uses plain old std::multimap for its backing; the .value() method implementation on it calls `.find(key)` on the backing and if it returns a valid iterator, returns its value

however, the standard std::multimap documentation for the .find() method says:

"If there are several elements with the requested key in the container, any of them may be returned."

so qt is placing expectations on behavior of multimap outside of the bounds of the standard, which libcxx validly follows

i think in practice this is unlikely to break anything much? i don't see much real world code relying on multimaps at all, let alone the specific lookup order

but just in case anyone else scratched their head over this for a couple hours