genuinely remarkable, the altogether perhaps even productive mischief you can get up to, especially with `__VA_OPT__` becoming a proper standard in both C and C++ so you don't have to feel dirty about using it.
i recently made use of plenty of ugly tricks in this vein to take a single authoritative table of macro invocations that defined a bunch of pixel formats, and make them graduate from defining bitfield structs to classes with accessors that performed good old fashioned shifts and masks, all without ever specifying the individual bit offsets of channels, just their individual widths, and macro magic did the rest. no templates, no actual c++, could just as feasibly produce pure c bindings down the line by just changing a few names.
getting really into this stuff makes you stop thinking of c function-like macros as functions of their arguments as such, but rather unary functions of argument lists, where arity roughly becomes the one notion vaguely akin to typing in the whole enterprise, or at least the one place where the compiler exhibits behaviour resembling that of a type checker. this was especially true considering the entries in the table i wound up with were variadic, terminating in variably many (name, width) parenthesised tuples. and i just... had the means to "uncons" them so to speak. fun stuff.
this is worth it, imo, in precisely one context, which is: you want a single source of truth that defines fiddly but formulaic implementations spread across multiple files that must remain coordinated, and this is something you do infrequently enough that you don't consider it worthwhile introducing "real" "big boy" code gen into your build process. mind, you usually do end up having to commit to a little utility header that defines convenient macros (_Ex and such in the article), but hey. c'est la vie. basically x macros (https://en.wikipedia.org/wiki/X_macro) on heart attack quantities of steroids.
multiple services depending on different outputs of a single acme client can be expressed, right now, in 2025, within systemd unit definitions, without deeply integrating a systemd-certd-or-whatever-as-such.
which is basically ideal, no? for all the buy-in that the systemd stapling-svchost.exe-onto-cgroups approach asks of us, at the very least we have sufficiently expressive system to do that sort of thing. where something on the machine has a notion of what wants what from what, and you can issue a command to see whether that dependency is satisfied. like. we are there. good. nice. hopefully ops guys are content to let sleeping dogs lie, right?
the nonprofit line has not been believ{ed,able} or relevant for what, in tech, may as well have been a century by now. had this happened around the time the veil was lifted, that would have been something worth discussing, but this was announced last month. it is now only meaningfully addressable along the same avenue as any other american tech giant getting comfy with the us govt's controversial foreign relations.
I think it's worth discussing AI specifically being used by authoritarian governments, because it is so suitable for surveillance and repression. And worth discussing OpenAI as a leader in the field, investing in such collaborations.
It's worth talking about the others too for sure.
Not every article or essay needs to talk about all of them. Sure, it would be improved if it at least mentioned in passing what is known of any other large corporations making specifically AI deals with authoritarian governments. (Such as all of them with Israel).
But not every article needs to talk about everything. The argument that a given article or point should not have been made because it didn't talk about other things -- usually will result in less talk about any of the things, not more. And that's often the intent of such an argument.
i remember looking through these during a deep dive on type selection -- naturally radon, krypton, and arguably xenon come across as a bit gimmicky, argon has stiff competition in its genre as it's the rough style of most “modern” monospace faces, but neon is actually kind of spicy. this is the closest to the “mona” in “monaspace”, being similarly derived from helvetica and its ilk, and sits at just that right level of regularity that it's easy on the eyes after a long day in a way that i previously thought was only the purview of sf mono.
the tragedy of both argon and fragment mono, though, is that the latter comes in one width, and the former inexplicably supports obscenely wide proportions without letting you condense it down from the bog-standard 1x2ish. most condensed options out there are these pill-shaped straight-walled monstrosities that blur together (the iosevkas and pragmatas of the world), with a few notable exceptions (the old osdn releases of mplus).
i wonder what would happen if you went in and extrapolated the width scaling for monaspace backwards into super narrow range.
for starters, toolbox grouping and icon theme changes are reversible in settings, and in fact the "legacy" icons have gotten a lot of love in 3.0. they look nice at high dpi now! (it's a shame we moved away from the tango aesthetic in linux land too early because god the style can look so right and crisp on hires screens)
having used all the 3.0 RCs up till now, i can assure you all gtk3 has done is made life nicer on all major platforms. for gimp's faults (now markedly fewer) it's an image editor, a thing with a distinct purpose and pretty immediate feedback on indulgent changes nuking productivity. the cancerous low-information-density, look-over-feel trends that we associate with new gtk versions by way of gnome's visionless bikeshedding blessedly does not translate to this new gimp. pinky promise. go use it. you'll like it.
Yeah, I don't buy this "we just hid the nice way behind an option" explaination, I've been stung by that too many times to ignore it..
It means "this gonna get dead" and the argument will be "oh, nobody uses it" yeah, because, you can only want a nice thing back if you knew it existed to begin with, eventually, most users either never knew it was there, or assumed it went away, and eventually, forget it entirely, and then it's gone.
I don't think you have to worry about settings disappearing in newer releases.
Which, major releases of Gimp are so slow anyways, if it was a realistic worry for this software specifically (it's not), it would probably be 10+ years before such a change hit stable.
you can slap a hash on a binary distribution and it becomes "reproducible" in the same trivial sense as any source tarball. after that, the reproducibility of whatever "build process" takes place to extract archives and shuffle assets around is no more or less fraught than any other package (probably less considering how much compilers have historically had to be brought to heel, especially before reproducibility was fashionable enough for it to enter much into compiler authors' consideration!!)
i recently made use of plenty of ugly tricks in this vein to take a single authoritative table of macro invocations that defined a bunch of pixel formats, and make them graduate from defining bitfield structs to classes with accessors that performed good old fashioned shifts and masks, all without ever specifying the individual bit offsets of channels, just their individual widths, and macro magic did the rest. no templates, no actual c++, could just as feasibly produce pure c bindings down the line by just changing a few names.
getting really into this stuff makes you stop thinking of c function-like macros as functions of their arguments as such, but rather unary functions of argument lists, where arity roughly becomes the one notion vaguely akin to typing in the whole enterprise, or at least the one place where the compiler exhibits behaviour resembling that of a type checker. this was especially true considering the entries in the table i wound up with were variadic, terminating in variably many (name, width) parenthesised tuples. and i just... had the means to "uncons" them so to speak. fun stuff.
this is worth it, imo, in precisely one context, which is: you want a single source of truth that defines fiddly but formulaic implementations spread across multiple files that must remain coordinated, and this is something you do infrequently enough that you don't consider it worthwhile introducing "real" "big boy" code gen into your build process. mind, you usually do end up having to commit to a little utility header that defines convenient macros (_Ex and such in the article), but hey. c'est la vie. basically x macros (https://en.wikipedia.org/wiki/X_macro) on heart attack quantities of steroids.