This blog post is a sequel to Your _get_type() function is not G_GNUC_CONST.
GNOME developers have long used G_GNUC_CONST, which expands to __attribute__((const)), to annotate GObject _get_type() functions, despite knowing that it is incorrect to do so. const functions by definition have no side effects, but _get_type() functions actually have a side effect the first time the function is called: they initialize the type. Why apply an incorrect annotation to these functions? Because it makes the code faster.
Although this was long known to be incorrect, it worked fine in practice… until now. Regrettably, Sam James has discovered that GCC 16 may optimize away the type initialization, resulting in crashes. This is our fault for providing the compiler with wrong information about our code, so it’s time to audit your use of const attributes to remove them from _get_type() functions. Most GNOME programs use these attributes only for _get_type() functions, but if you use it in more places, then check to make sure those functions are actually const, as defined by the GCC documentation.
Sadly, there is no suitable replacement attribute for _get_type() functions. Two decades ago, Behdad requested a new idempotent attribute for expressing the desired semantics, but nobody has implemented it.
File under: brief half-year catch-ups, me not remembering when I last updated the back-end of this blog
I’m writing this from a terrible AirBnB in Reading, having just wrapped up a four-day visit to my old Typography & Graphic Communication alma mater and happy to have an excuse to put off re-packing. I’ve been fortunate in the first six months of this year to have time to participate in a number of in-person conferences after a few years of not being able to travel, and when I was looking back at the calendar I noticed that these events have been evenly split between FOSS events and type-related events, so I decided it’s worth jotting down a few of the thoughts that presented themselves before they fade away entirely. Here’s a recap:
SCALE: The Southern California Linux Expo (which, for the record, I refuse to bacronymize in a mixed-case form, so don’t at me about the capital A). I’ve been a regular for yikes years at this point, and have helped coordinate the “libre graphics track” for the past several, but this time I actually had to present a workshop as part of that. It was on the subject of learning Scribus if you’re coming from the world of LibreOffice / Microsoft Word / Google Docs / Etc. Turns out that’s an ambitious subject, scope-wise, and we didn’t get through everything I wanted to.
But for me, that highlights the fact that shifting from one Do Real Work application to another is always a monumental effort. Sure, you can fire up GIMP and do some cropping of images in a matter of minutes. But you can’t drop a full production workflow without a lot of spare time, because every individual sub-task now involves a different order of operations (or different operations), a different cycle of tool-switching, and a different set of cross-checks and QA. I don’t think we give this problem enough attention, especially when the well-meaningers on social media (and yeah, that includes Mastodon, as fully as whatever platform you don’t like) entice people to give it a try like it’s no big thing.
It also reiterated for me how important document templates are. Those are fairly forgettable 99% of the time, but what ships in the template choosers of LibreOffice, WhateverOfficeOnline, and in more specialist apps is what people end up using when they need to get things done. The typography in most FOSS templates is pretty awful: the fonts are weak, the hierarchies are non-existent, the alignments are haphazard, and the optical balance is even more non-existent than the hierarchies. I suspect that this can only being improved with a long, slow, many-person grind. I don’t know where to start.
WAVE and ATypI: Both of these are type-related or type-adjacent events, so I don’t have much that feels relevant to say about them here. WAVE is quite specialized, since it focuses on human writing: just as many of the presenters are linguists as anything else, and the type people made a stronger showing this year than they did in the original event a couple of years back but aren’t the majority. It is genuinely a wake-up call to sit down and learn about a written language that does not operate in the way that your own does, and to hear exactly how many people use it every day (as well as to see photos to remind you that all of this happens in the present, when it’s incredibly easy to write off those concerns as belonging to an earlier era in printing and just presume that Computers Fixed All That. Or that OpenType and Unicode did. Or that FOSS did.).
I do think, however, that most of the FOSS projects I’m involved with keep a stout set of blinders on about non-majority language systems and scripts, and that that’s deeply problematic. Indeed, it was not long ago that I mentioned IRL that GNOME could do a valuable bit of good for the global user community by finding and supporting scripts other than Latin/Greek/Cyrillic — in contrast to today, where the attitude is “oh, those users will figure it out for themselves like they always do aren’t they great over there” and/or “Noto Fixed All That.” It’s not hard to say that the next release of your project will also support, say, Arabic, and to at the very least be deliberate about bringing people into the room to find and test the fonts you need to determine if things are working and look good. Yes, you do have to do actual tests. Yes, I mean you.
ATypI, in contrast, is very much a “type production” event. For me, this year the bit that stood out was behind-the-scenes stuff that eeped out around the seams and got more widely discussed. Like, there was evidently initial interest from some on the local organizing side that there would be a verrrry small list of presenters: less than two dozen, total, for 3–4 days (depending on how you count workshops and exhibits). Far less than two dozen. There are two big gotchas there. First, you have to contend with gatekeeping. All of the well-known people are likely to be the ones with The Exciting Announcement to announce and, in theory, they’re a big part of the draw. But that keeps all the new community members out. Second, it crashes the economic viability of attending the event. The locale this time was Stanford, which (despite being perhaps the world’s only Junior University, look it up) is outrageously expensive, even if you already live outrageously in nearby northern California. And any time people can’t justify the cost of travel, yes you’re gatekeeping again (particularly of the hallway track), but you’re also twisting the dial on your conference further from “I Should Go” over to “Going Is Just Paying Money To Be In The Audience Of A YouTube Video That I Can Watch Any Other Time” … which is a hard dial to reverse.
LGM: The Libre Graphics Meeting seems to be back on its feet and in good form after several post-pandemic years of bumping into things. Massive props. I had a lot of side-project stuff I brought along in disorganized form, although I attended every session. I also quasi-roundtabled a session to talk about how the now defunct “Planet LibreGraphics”, may it rest unpeacefully, used to be the clear answer to the perpetual question of “how do we maintain momentum and connection the rest of the year?”
But whereas the old Planet site was a garden variety class-M aggregator of individual blogs’ RSS or Atom feeds, I’m of the unprofessional opinion that a true community aggregator today has to account for different types of inputs and outputs and user modes (sideputs?). E.g., many projects don’t announce new releases on their project blog anymore; they tag a release on GitHub. That’s a different input. A lot of people don’t post long-form content anymore, but do a lot of microblogging. That might suggest having an ActivityPub output … but it would be a bot, and it would incur a TON of overhead and put scores of messages out all day long, which you definitely couldn’t use on the traditional RSS output. So you probably need to handle those differently, maybe batching the Mastodon bits into a once-per-day blog output?
Ultimately, I’m not sure; there are a lot of these details. We’re way out in the high-cosmic-ray environment of the trans-neptunians here, or some other metaphor. Ping me if you find the question interesting, because I want to talk a lot more about it.
LAS: It was my first time going to the Linux Application Summit, as the kids call it these days, so I have more thoughts to get down about that one. For starters, it wasn’t what I expected, because I expected there to be more people there who develop Linux applications. I covered a lot of growth of post–CD-delivered-and-RPM/Apt-updated packaging efforts when I was toiling as a not-so-young FOSS journalist, so I do think I have the right grounding in systems like Snap, Flatpak, FlatHub, AppKit, immutable-image OS approaches and other user-code–confinement technical building blocks. Except Kubernetes; I never cared about that and never will.
Anyway, all of that stuff (hand-waving) is very much where LAS takes place. It’s really good to see that there are people from multiple application ecosystems talking about how they handle the current set of unsolved problems. Selfishly, one of the sessions that stood out most to me was Carlos Garnacho’s talk about the data-search layer that he’s been working on. The gist there is that it’s for searching local data … which you might think you can already do, but you’d be wrong. You can sort of do filesystem-level text searching, but that doesn’t handle complex stuff, and it really, really doesn’t let you handle per-application searching well. I’ve got a keen interest in what people do with their “big data exports” — we FOSS people like to look down our noses at the public and tell them that they should take all of their content out of The Bad Services and walk into the sunlight. But there’s not anything they can do with it when they get here (or there, depending on how you feel), and they’re the ones holding the bag. The TinySparql and LocalSearch stuff, I think, holds the potential to improve on that in a big way.
I was also quite interested to learn more about how the KDE ecosystem does its builds. I don’t do … builds, at least not in the sense that KDE and GNOME do (nor, who else, who else … Enlightenment, maybe?). But I have been forced against my will to get up to speed on some things like GitHub Actions, and the session about KDE’s build architecture did make me want to go back and re-examine some stuff I’ve built. That being the other sense of “build.” I was also very interested in Evangelos Paterakis’s talk about the gritty realities of picking up an abandoned project, reviving it in fork-form, and getting hit with the consequences of that discussion from both upstream and downstream.
For most people, what matters in these sort of pseudoplumbing projects in what’s going to be accessible in end-user applications whenever they land on the next platform releases. That’s why I thought I might encounter app developers at LAS. Instead, much of the session content was about enhancing the the plumbing layer themselves: what’s going on with portals, how sandbox/confinement techniques either fail-open or fail-close, and where the confined-application model is still leaking.
I suggest checking out Sebastien Wick’s talk about the portal situation if nothing else; the slides are available now, even if the video is not. Whenever the videos go up, I also suggest that everyone watches the session about forking a defunct project … not because it’s something everyone should do, although let’s face it, projects appear and fizzle all the time. But mainly because the social aspects of how a revived fork does or doesn’t catch on are things the FOSS community doesn’t say out loud. Not bad or shameful things, just sharp corners.
All that said, I think that what really needs to happen is for application developers to actually go to this event. I know you think you don’t need to. But the platform layer is another one of those things about which you can easily say “Didn’t Somebody Already Handle That?” and be incorrect for a long period of time before it bites you. Moreover, every time I’ve ever asked the developer of a Mac or Windows desktop app what they know about developing Linux apps, they tell me a story about running into giant potholes, missing documentation, and mismatched API expectations. The presence of Linux app developers at a plumbing-layer conference will not instantly fix that, but I do know that a lot of those Linux developers hit the same roadblocks.
LGM made a massive improvement to the ecosystem of creative-arts apps in FOSS specifically because it involved getting users, app developers, and subsystem developers into a single space. That’s not a magic trick, and the general Linux app universe would benefit from repeating the technique.
Grapholinguistics in the 21st century, also known as /gĘafematik/: This is the one I just came from, and I don’t quite have it all simmered from ingredients into stew just yet. Apart from being hosted in an initially un-airconditioned spot at the university in the hottest UK week since 1666, I don’t think I have any complaints. I introduced speakers and acted as moderator for Q&A blocks, and apart from that I visited with most but not all of the rest of the quantitative type-research clique. You know where to find us.
One takeaway, perhaps, that will be generally useful is that I spent much of the inter-session time when I was on moderator duty trying to gauge the level of nervousness of the upcoming speaker and attempting to defuse it. I don’t know how successful that actually was, but I do think there were sessions elsewhere where it might have made a difference. I don’t know; perhaps that’s projecting.
Anyway, before the Internet runs out of bits, I should wrap up. I do need to be sure to express my appreciation to the GNOME Foundation, who chipped in with some travel expense assistance for LAS, as well as to my friend and mentor-in-a-few-very,-very-limited-capacities-I-can’t-emphasize-that-part-enough Sri Ramkrishna for pinging me about it and then reminding me. I’m definitely glad I went.
At the moment, I’m halfway through reconfiguring the blog site here into static format (fighting Unicode support in the old platform), so don’t count on commenting to work. If you want to reply to anything I said here, try me on Mastodon.
Read more of this story at Slashdot.
Read more of this story at Slashdot.
Read more of this story at Slashdot.
Read more of this story at Slashdot.
Read more of this story at Slashdot.
Read more of this story at Slashdot.
Read more of this story at Slashdot.
Read more of this story at Slashdot.
Read more of this story at Slashdot.
Read more of this story at Slashdot.
Read more of this story at Slashdot.
Read more of this story at Slashdot.
Read more of this story at Slashdot.
Read more of this story at Slashdot.
Read more of this story at Slashdot.