Last week, like many other people, I was in Berlin for the Mega^WGoals sprint. Natually the three goals (Sustainability, Accessibility, and Automatability; the three abilities) attracted a diverse crowd of people that brought also other topics, so it turned into a proper megasprint.

Being interested in all three goals made it a bit callenging to follow all relevant discussions unfortunately, but on the flip side it never got boring.

Most of my goal-related work was towards the automation goal. One thing I was working on is a CI job that checks for spelling mistakes in the code, so that those can be caught when doing a MR. A while ago I create a website that tracks which KDE projects are ported to Qt6. What started out as a joke for a talk turned out to be a useful tool for planning porting work. During the print I fixed the site to actually work correctly again and, most importantly, changed the text from "No" to "Yes" since most projects actually use Qt6 now. For a while the site also has auto-generated reports for other things, like showing which projects don't yet have clang-format applied to them or which projects don't enforce passing test in the CI. I used the latter list to enable this for the remaining projects that don't have failing tests right now and prepared a change to the CI system that enforces passing tests by default. In the same spirit others and I also fixed some currently failing tests. We also discussed the idea of extending the site with more checks and turning it into a proper KDE site that isn't hosted on my personal infrastructure.

Harald, Carl, and I worked on a dashboard to show the CI status for our project. This is something we haven't really had since switching to Gitlab CI but is very useful e.g. as part of the release checklist. We do have a working prototype, but some things remain to be ironed out. As part of this we also fixed some of the currently failing builds.

My main contribution to the systainability goal was debugging why Nate's NeoChat is using too much CPU. With a team effort we eventually pinpointed this to an invisible animation constantly repainting the window, which was then promptly fixed.

In terms of accessibility I was mainly involved in discussions about challenges and new developments with accessibility on Wayland. Expect to hear more on this soon.

In "off-topic" topics there were plently of discussions about visions, ideas, and challenges for our application development story. This included discussions on visions for design/UX, theming, API design, and software distribution. Being KDE's Software Platform Engineer it is part of my responsibilities to facilitate these kinds of discussions. Later this year I want to host a sprint dedicated to application design to discuss and establish our vision there. If you are interested do reach out to me.

All in all it was a fun few days with great people. Thanks to MBition and Aleix for hosting us, and thanks to those donating to KDE to make these sprints possible.

01 May 2024 1:00pm GMT

International Workers' Day marks the release of Workbench 46.1

This new release comes with

Save/restore window state and dimensions for each session/project. I couldn't use the method defined in Saving and restoring state into GSettings because resizing manually with the mouse triggers a lot of blocking disk writes and cause the user action to appear sluggish. So I debounce the events and write to gsettings manually.

Find text in the current editor. The keyboard shortcut is Ctrl+F. This is a feature started by Sriyansh Shivam during their GSoC 2023 internship and finished by UrtsiSantsi. Thanks!

SVG Library entry. Gtk (via gdk-pixbuf) draws SVGs at their intrisic sizes (what is defined in the svg document). If you use different dimensions for example using GtkImage.pixel-size then it is the pixmap that gets upscaled resulting in pixelated / blurry images. This new Library entry showcases how to render an SVG at arbitrary dimensions using librsvg. We may need a better primitive in the future, if you need an SVG Paintable; GTK Demo contains an example. See also this conversation.

Reveal In Files. This is a new option available in the menu that will reveal the session/project in Files. You can use it to add assets to your project and load them using workbench.resolve or as icons.

Import icons into your projects. Using the "Reveal In Files" option you can now add custom icons to your projects. It's just a matter of dropping the files in the right folder. See the "Using Icons" Library entry.

Workbench included an Icon Library and icon-development-kit for a while but in an effort to simplify Workbench and since we already have an Icon Library app, I decided to remove both in favor of per project icons.

I'm quite happy with the developer experience there and I hope we can provide something similar in the future to move beyond GtkIconTheme. We probably need to keep icon-name as suggested in Updates from inside GTK but I'd be very interested supporting relative paths in GTK Builder. Thankefully we already have GResource to allow for something like

Gtk.Image {
  src: "./smile-symbolic.svg";
}

7 new Library entries ported to Vala

• Radio Buttons
• Switch
• Revealer
• Styling with CSS
• Separator
• Level Bars
• Link Button

Also

• "Animation" Library entry ported to Python
• Split "List View Widget" Library entry into "List View" and "Grid View"
• Fix Vala and Rust extensions detection on "Run"
• List editor shortcuts in Shortcuts

Thank you contributors and GSoC applicants.

01 May 2024 7:51am GMT

Looking back at my blog, I find lots of mention of Amarok, the KDE audio player, in 2008, 2009, some KDE4-on-OpenSolaris stuff mentions it, and then a long silence until 2021. About a year ago, early 2023, the audio/amarok port was removed from FreeBSD ports. So naturally I was intrigued - maybe even excited - to see Amarok return from vacation with a 3.0 release. And I needed to try it on FreeBSD.

Many of the dependencies are (still) packaged on FreeBSD, so I installed a handful and tried building it on my still-KF5-based X11-based so last-gen Plasma Desktop workstation.

Somewhat to my surprise - I don't imagine there is FreeBSD CI for Amarok - everything built, ninja install did the right things, and it starts! And toots and parples, clangs, bangs, blips and bloops are reproduced with excellent fidelity.

So, congratulations Amarok folk. It might even return to the FreeBSD ports collection, although - I'm gonna be honest here - I'm not sure it offers me anything in the way of music appreciation that command-line gst-play doesn't give me. I am just that much more previous-last-gen.

30 Apr 2024 10:00pm GMT

The GNOME Foundation invites bids for hosting GNOME Asia 2024. This is your chance to bring GNOME Asia to your city!

If you are interested in submitting a proposal to host GNOME Asia in your city, please submit an intent to bid by filling out this short form. Intent to Bid submissions are due by end-of-day May 15, 2024.

Final proposals should be submitted using our online form and are due by June 6, 2024.

Be prepared to include the following details in your proposal:

• Location information
• A list of local team members
• Information about local support (GNOME or open source communities, universities, government or businesses affiliated with GNOME or open source)
• Ideas about local sponsors
• Venue information
• Proposed dates
• Travel information (local airports, trains, etc.)
• Local transportation (how will attendees get around the city)
• Accommodation and dining options
• Social event options
• Group activity options
• Estimated costs and budget for hosting in this location

Deadlines
Intention to bid: May 15, 2024
Final proposal submission: June 6, 2024

Proposals from previous years are available for reference and you can talk to the Foundation Board and previous GNOME Asia organizers to find out more about what is involved. If you need more time to finalize your bid please contact kprogri@gnome.org.

Organizing GUADEC is a large undertaking but local teams will have help from Foundation Staff members and Engagement Team contributors!

If you have any questions, don't hesitate to contact Kristi at kprogri@gnome.org or the GNOME Asia team at asia@gnome.org.

Submit an Intent to Bid
Submit a Proposal

30 Apr 2024 5:51pm GMT

I was looking at some code that sets file permissions - file modes - by calling chmod(2). The command-line chmod(1) has a bunch of possibilities for setting permissions, but the underlying system-call needs an int, and the C headers for it are annoying to use. So I fired up some C++ machinery to "make it nicer to use".

tl;dr: scroll to the bottom for a compile-time, compact way of writing file permissions so that chmod(filename, "rwx--x--x"_mode) does something plausible, with good error messages in case of typo's.

The manpage for chmod(1) is fairly extensive. There are two ways to specify a file mode, either in octal or symbolically. Octal is just a number, symbolically is much more complicated.

On the C API side, the manpage for chmod(2) shows you need a pathname and a mode, and there are a whole bunch of symbolic constants to use, like S_IRUSR.

How I think about file modes

It turns out I nearly always think about file modes in octal. I have somehow internalized things like "755 for executables" and "666 for crap" and "600 for files in ~/.ssh" but I don't really have names for these things. If I think about it, I can use the symbolic manipulations like ugo+rw for crap. But I don't see permissions in this symbolic form, and the octal form is persnickety in C source, probably because I don't expect everyone to know "leading 0 means octal".

But there is a form in which I see file modes every day: the output from ls -l, where permissions are shown with 10 characters, the first 10 on this line:

-rw-r--r-- 1 adridg users 0 Apr 30 11:46 example.txt

The first - says something about the type of file and is - for regular files, d for directories, l for symbolic links, and there are others, too. That's not really the mode, though, while the next 9 characters are: each group of three shows r, w, and x in that order, or a - in each position, indicating the read, write, or execute bit for the corresponding class of logins. The first three are the current user, next three are group, the last three for others.

The C code to call chmod with this mode looks like

chmod("example.txt", 0644);
chmod("example.txt", S_IRUSR | S_IWUSR | S_IRGRP | S_IROTH);

One is octal-arcane and the other is just arcane and hard-to-read.

Turning readable modes into numbers

So I thought to myself: I can write a C++ function that turns the 9-characters of the mode in text form, into an actual mode_t value (that's an integer).

That's a trivial exercise, really, although it gets a bit persnickety in error handling. I would just throw on an incorrect length, or any incorrect character, and leave it at that.

From there, though, I went on to: I can write a consteval C++ function that does the computation at compile-time (guaranteed to be only at compile-time, because consteval). This is a function that can only be called with a compile-time string literal, so the function signature is potentially:

consteval mode_t from_readable_mode(const char (&permission_string)[10])

The array-reference is to 10 characters because there are 9 mode characters, and then a trailing NUL byte (zero) in a string literal. This function can be called (in the context, sill, of chmod()) like so:

chmod("example.txt", from_readable_mode("rw-r--r--"));

and at compile-time that is already computed to be 420 (that's 0644 octal).

The last step of make-it-cool (for an appropriate value of "cool") is to turn the whole thing into a user-defined literal. In my source code I can now write

chmod("example.txt", "rw-r--r--"_mode);

Which really satisfies my own desire for "readable, compact, compile-time".

Don't get me started on Qt

For some reason, the values of QFileDevice::Permission are in hexadecimal, but written as hex, look like the corresponding octal values. So in Qt code if you don't use the symbolic representation of the flags, and just go ram an integer into there, you get 0x644 meaning the same as 0660 in the call to chmod() and everything becomes just that much more confusing and fraught.

Meaningful error messages

C++ and "helpful, friendly, easy-to-read error messages" go together like peaches and .. battery acid? Like things that don't go well together at all. In recent GCC versions there has been a marked improvement in the look of error messages.

With some judicious use of templates and naming of types, existing error messages can be improved. You still get a veritable torrent of messages, but if, somewhere in the middle, the error message (here, from Clang 17) says:

mode.h:26:9: note: subexpression not valid in a constant expression
26 | throw invalid_permission_character{};
mode.h:41:9: note: in call to 'expected_character_at_position(&"rwxbadbug"[0])'
41 | detail::expected_character_at_position<3, 'r'>(s) |

Then it's a lot easier to decide that the character at position 3 - the letter b - is not expected, and maybe an r was expected there instead.

User-defined file mode literals

Here is the definition of my _mode literal. String-based literals get a pointer and a size, which is inconvenient because they don't turn back into fixed-size arrays.

consteval mode_t operator""_mode(const char *s, size_t len)
{
if (len != 9)
{
throw detail::invalid_permission_string_length{};
}
return detail::from_readable_mode_string(s);
}

Anyway, if the string is the wrong size then a meaningful exception is thrown, which isn't constexpr, so you get a meaningful error message:

mode.h:65:9: note: subexpression not valid in a constant expression
65 | throw detail::invalid_permission_string_length{};
main.cc:44:24: note: in call to 'operator""_mode(&"birb"[0], 4)'
44 | std::cout << "birb"_mode;

Here us the implementation of the function that does the actual work, turning the string into a mode_t:

consteval mode_t from_readable_mode_string(const char * const s)
{
return
detail::expected_character_at_position<0, 'r'>(s) |
detail::expected_character_at_position<1, 'w'>(s) |
detail::expected_character_at_position<2, 'x'>(s) |
detail::expected_character_at_position<3, 'r'>(s) |
detail::expected_character_at_position<4, 'w'>(s) |
detail::expected_character_at_position<5, 'x'>(s) |
detail::expected_character_at_position<6, 'r'>(s) |
detail::expected_character_at_position<7, 'w'>(s) |
detail::expected_character_at_position<8, 'x'>(s);
}

It's really wordy, which is unfortunate, but by writing it like this, the error message - at least with Clang 17 - repeats the template parameters and mentions the specific subexpression that is problematic.

Here is a Clang 17 error message when using an inappropriate permission character:

mode.h:26:9: note: subexpression not valid in a constant expression
26 | throw invalid_permission_character{};
mode.h:44:9: note: in call to 'expected_character_at_position(&"------uwu"[0])'
44 | detail::expected_character_at_position<6, 'r'>(s) |
mode.h:67:12: note: in call to 'from_readable_mode_string(&"------uwu"[0])'
67 | return detail::from_readable_mode_string(s);

Huh, I guess you can't give uWu permission to others. The same error message from GCC 13 looks similar:

main.cc:44:18: in 'constexpr' expansion of 'operator""_mode(((const char*)"------uwu"), 9)'
mode.h:67:45: in 'constexpr' expansion of 'detail::from_readable_mode_string(s)'
mode.h:44:55: in 'constexpr' expansion of 'detail::expected_character_at_position<6, 'r'>(((const char*)s))'
mode.h:26:9: error: expression '<throw-expression>' is not a constant expression
26 | throw invalid_permission_character{};

And here's the implementation that turns a single character into a bit in a file mode value:

template<int position, char accept>
consteval mode_t expected_character_at_position(const char * const permission_string)
{
const char c = permission_string[position];
if(c == accept) { return 1 << (8-position); }
if(c == '-') { return 0; }
throw invalid_permission_character{};
}

This is a bit wordy, but it ensures that position and the acceptable (expected) char are front-and-center in error messages, and that the expected character and - are the only characters for which this is a constant expression - everything else will fail because exceptions aren't constexpr.

So there you have it, a compact constexpr representation of file modes with meaningful error messages. You can find the code in my personal GitHub repository playground, in the subdirectory mode/ . I won't link it here because, frankly, it is time I get my ass in gear and migrate to some other forge.

29 Apr 2024 10:00pm GMT

The firmware which drm/kms drivers need is becoming bigger and bigger and there is a push to move to generating a generic initramfs on distro's builders and signing the initramfs with the distro's keys for security reasons. When targetting desktops/laptops (as opposed to VMs) this means including firmware for all possible GPUs which leads to a very big initramfs.

This has made me think about dropping the GPU drivers from the initramfs and instead make plymouth work well/better with simpledrm (on top of efifb). A while ago I discussed making this change for Fedora with the Red Hat graphics team spoiler: For now nothing is going to change.

Let me repeat that: For now there are no plans to implement this idea so if you believe you would be impacted by such a change: Nothing is going to change.

Still this is something worthwhile to explore further.

Advantages:

1. Smaller initramfs size:

* E.g. a host specific initramfs with amdgpu goes down from 40MB to 20MB
* No longer need to worry about Nvidia GSP firmware size in initrd
* This should also significantly shrink the initrd used in liveimages

2. Faster boot times:

* Loading + unpacking the initrd can take a surprising amount of time. E.g. on my old AMD64 embedded PC (with BobCat cores) the reduction of 40MB -> 20MB in initrd size shaves approx. 3 seconds of initrd load time + 0.6s seconds from the time it takes to unpack the initrd
* Probing drm connectors can be slow and plymouth blocks the initrd -> rootfs transition while it is busy probing

3. Earlier showing of splash. By using simpledrm for the splash the splash can be shown earlier, avoiding the impression the machine is hanging during boot. An extreme example of this is my old AMD64 embedded PC, where the time to show the first frame of the splash goes down from 47 to 9 seconds.

4. One less thing to worry about when trying to create a uniform desktop pre-generated and signed initramfs (these would still need support for nvme + ahci and commonly used rootfs + lvm + luks).

Disadvantages:

Doing this will lead to user visible changes in the boot process:

1. Secondary monitors not lit up by the efifb will stay black during full-disk encryption password entry, since the GPU drivers will now only load after switching to the encrypted root. This includes any monitors connected to the non boot GPU in dual GPU setups.

2. With simpledrm plymouth does not get the physical size of the monitor, so plymouth will need to switch to using heuristics on the resolution instead of DPI info to decide whether or not to use hidpi (e.g. 2x size) rendering and even when switching to the real GPU driver plymouth needs to stay with its initial heuristics based decision to avoid the scaling changing when switching to the real driver which would lead to a big visual glitch / change halfway through the boot.

This may result in a different scaling factor for some setups, but I do not expect this really to be an issue.

3. On some (older) systems the efifb will not come up in native mode, but rather in 800x600 or 1024x768.

This will lead to a pretty significant discontinuity in the boot experience when switching from say 800x600 to 1920x1080 while plymouth was already showing the spinner at 800x600.

One possible workaround here is to add: 'video=efifb:auto' to the kernel commandline which will make the efistub switch to the highest available resolution before starting the kernel. But it seems that the native modes are simply not there on systems which come up at 800x600 / 1024x768 so this does not really help.

This does not actually break anything but it does look a bit ugly. So we will just need to document this as an unfortunate side-effect of the change and then we (and our users) will have to live with this (on affected hardware).

4. On systems where a full modeset is done the monitor going briefly black from the modeset will move from being just before plymouth starts to the switch from simpledrm drm to the real driver. So that is slightly worse. IMHO the answer here is to try and get fast modesets working on more systems.

5. On systems where the efifb comes up in the panel's native mode and a fast modeset can be done, the spinner will freeze for a (noticeable) fraction of a second as the switch to the real driver happens.

Preview:

To get an impression what this will look / feel like on your own systems, you can implement this right now on Fedora 40 with some manual configuration changes:

1. Create /etc/dracut.conf.d/omit-gpu-drivers.conf with:

omit_drivers+=" amdgpu radeon nouveau i915 "

And then run "sudo dracut -f" to regenerate your current initrd.

2. Add to kernel commandline: "plymouth.use-simpledrm"

3. Edit /etc/selinux/config, set SELINUX=permissive this is necessary because ATM plymouth has issues with accessing drm devices after the chroot from the initrd to the rootfs.

Note this all assumes EFI booting with efifb used to show the plymouth boot splash. For classic BIOS booting it is probably best to stick with having the GPU drivers inside the initramfs.

29 Apr 2024 1:46pm GMT

The firmware which drm/kms drivers need is becoming bigger and bigger and there is a push to move to generating a generic initramfs on distro's builders and signing the initramfs with the distro's keys for security reasons. When targetting desktops/laptops (as opposed to VMs) this means including firmware for all possible GPUs which leads to a very big initramfs.

This has made me think about dropping the GPU drivers from the initramfs and instead make plymouth work well/better with simpledrm (on top of efifb). A while ago I discussed making this change for Fedora with the Red Hat graphics team spoiler: For now nothing is going to change.

Let me repeat that: For now there are no plans to implement this idea so if you believe you would be impacted by such a change: Nothing is going to change.

Still this is something worthwhile to explore further.

Advantages:

1. Smaller initramfs size:

* E.g. a host specific initramfs with amdgpu goes down from 40MB to 20MB
* No longer need to worry about Nvidia GSP firmware size in initrd
* This should also significantly shrink the initrd used in liveimages

2. Faster boot times:

* Loading + unpacking the initrd can take a surprising amount of time. E.g. on my old AMD64 embedded PC (with BobCat cores) the reduction of 40MB -> 20MB in initrd size shaves approx. 3 seconds of initrd load time + 0.6s seconds from the time it takes to unpack the initrd
* Probing drm connectors can be slow and plymouth blocks the initrd -> rootfs transition while it is busy probing

3. Earlier showing of splash. By using simpledrm for the splash the splash can be shown earlier, avoiding the impression the machine is hanging during boot. An extreme example of this is my old AMD64 embedded PC, where the time to show the first frame of the splash goes down from 47 to 9 seconds.

4. One less thing to worry about when trying to create a uniform desktop pre-generated and signed initramfs (these would still need support for nvme + ahci and commonly used rootfs + lvm + luks).

Disadvantages:

Doing this will lead to user visible changes in the boot process:

1. Secondary monitors not lit up by the efifb will stay black during full-disk encryption password entry, since the GPU drivers will now only load after switching to the encrypted root. This includes any monitors connected to the non boot GPU in dual GPU setups.

2. With simpledrm plymouth does not get the physical size of the monitor, so plymouth will need to switch to using heuristics on the resolution instead of DPI info to decide whether or not to use hidpi (e.g. 2x size) rendering and even when switching to the real GPU driver plymouth needs to stay with its initial heuristics based decision to avoid the scaling changing when switching to the real driver which would lead to a big visual glitch / change halfway through the boot.

This may result in a different scaling factor for some setups, but I do not expect this really to be an issue.

3. On some (older) systems the efifb will not come up in native mode, but rather in 800x600 or 1024x768.

This will lead to a pretty significant discontinuity in the boot experience when switching from say 800x600 to 1920x1080 while plymouth was already showing the spinner at 800x600.

One possible workaround here is to add: 'video=efifb:auto' to the kernel commandline which will make the efistub switch to the highest available resolution before starting the kernel. But it seems that the native modes are simply not there on systems which come up at 800x600 / 1024x768 so this does not really help.

This does not actually break anything but it does look a bit ugly. So we will just need to document this as an unfortunate side-effect of the change and then we (and our users) will have to live with this (on affected hardware).

4. On systems where a full modeset is done the monitor going briefly black from the modeset will move from being just before plymouth starts to the switch from simpledrm drm to the real driver. So that is slightly worse. IMHO the answer here is to try and get fast modesets working on more systems.

5. On systems where the efifb comes up in the panel's native mode and a fast modeset can be done, the spinner will freeze for a (noticeable) fraction of a second as the switch to the real driver happens.

Preview:

To get an impression what this will look / feel like on your own systems, you can implement this right now on Fedora 40 with some manual configuration changes:

1. Create /etc/dracut.conf.d/omit-gpu-drivers.conf with:

omit_drivers+=" amdgpu radeon nouveau i915 "

And then run "sudo dracut -f" to regenerate your current initrd.

2. Add to kernel commandline: "plymouth.use-simpledrm"

3. Edit /etc/selinux/config, set SELINUX=permissive this is necessary because ATM plymouth has issues with accessing drm devices after the chroot from the initrd to the rootfs.

Note this all assumes EFI booting with efifb used to show the plymouth boot splash. For classic BIOS booting it is probably best to stick with having the GPU drivers inside the initramfs.

comments

29 Apr 2024 1:13pm GMT

It's been around 6 months since the GNOME Foundation was joined by our new Executive Director, Holly Million, and the board and I wanted to update members on the Foundation's current status and some exciting upcoming changes.

Finances

As you may be aware, the GNOME Foundation has operated at a deficit (nonprofit speak for a loss - ie spending more than we've been raising each year) for over three years, essentially running the Foundation on reserves from some substantial donations received 4-5 years ago. The Foundation has a reserves policy which specifies a minimum amount of money we have to keep in our accounts. This is so that if there is a significant interruption to our usual income, we can preserve our core operations while we work on new funding sources. We've now "hit the buffers" of this reserves policy, meaning the Board can't approve any more deficit budgets - to keep spending at the same level we must increase our income.

One of the board's top priorities in hiring Holly was therefore her experience in communications and fundraising, and building broader and more diverse support for our mission and work. Her goals since joining - as well as building her familiarity with the community and project - have been to set up better financial controls and reporting, develop a strategic plan, and start fundraising. You may have noticed the Foundation being more cautious with spending this year, because Holly prepared a break-even budget for the Board to approve in October, so that we can steady the ship while we prepare and launch our new fundraising initiatives.

Strategy & Fundraising

The biggest prerequisite for fundraising is a clear strategy - we need to explain what we're doing and why it's important, and use that to convince people to support our plans. I'm very pleased to report that Holly has been working hard on this and meeting with many stakeholders across the community, and has prepared a detailed and insightful five year strategic plan. The plan defines the areas where the Foundation will prioritise, develop and fund initiatives to support and grow the GNOME project and community. The board has approved a draft version of this plan, and over the coming weeks Holly and the Foundation team will be sharing this plan and running a consultation process to gather feedback input from GNOME foundation and community members.

In parallel, Holly has been working on a fundraising plan to stabilise the Foundation, growing our revenue and ability to deliver on these plans. We will be launching a variety of fundraising activities over the coming months, including a development fund for people to directly support GNOME development, working with professional grant writers and managers to apply for government and private foundation funding opportunities, and building better communications to explain the importance of our work to corporate and individual donors.

Board Development

Another observation that Holly had since joining was that we had, by general nonprofit standards, a very small board of just 7 directors. While we do have some committees which have (very much appreciated!) volunteers from outside the board, our officers are usually appointed from within the board, and many board members end up serving on multiple committees and wearing several hats. It also means the number of perspectives on the board is limited and less representative of the diverse contributors and users that make up the GNOME community.

Holly has been working with the board and the governance committee to reduce how much we ask from individual board members, and improve representation from the community within the Foundation's governance. Firstly, the board has decided to increase its size from 7 to 9 members, effective from the upcoming elections this May & June, allowing more voices to be heard within the board discussions. After that, we're going to be working on opening up the board to more participants, creating non-voting officer seats to represent certain regions or interests from across the community, and take part in committees and board meetings. These new non-voting roles are likely to be appointed with some kind of application process, and we'll share details about these roles and how to be considered for them as we refine our plans over the coming year.

Elections

We're really excited to develop and share these plans and increase the ways that people can get involved in shaping the Foundation's strategy and how we raise and spend money to support and grow the GNOME community. This brings me to my final point, which is that we're in the run up to the annual board elections which take place in the run up to GUADEC. Because of the expansion of the board, and four directors coming to the end of their terms, we'll be electing 6 seats this election. It's really important to Holly and the board that we use this opportunity to bring some new voices to the table, leading by example in growing and better representing our community.

Allan wrote in the past about what the board does and what's expected from directors. As you can see we're working hard on reducing what we ask from each individual board member by increasing the number of directors, and bringing additional members in to committees and non-voting roles. If you're interested in seeing more diverse backgrounds and perspectives represented on the board, I would strongly encourage you consider standing for election and reach out to a board member to discuss their experience.

Thanks for reading! Until next time.

Best Wishes,
Rob
President, GNOME Foundation

Update 2024-04-27: It was suggested in the Discourse thread that I clarify the interaction between the break-even budget and the 1M EUR committed by the STF project. This money is received in the form of a contract for services rather than a grant to the Foundation, and must be spent on the development areas agreed during the planning and application process. It's included within this year's budget (October 23 - September 24) and is all expected to be spent during this fiscal year, so it doesn't have an impact on the Foundation's reserves position. The Foundation retains a small % fee to support its costs in connection with the project, including the new requirement to have our accounts externally audited at the end of the financial year. We are putting this money towards recruitment of an administrative assistant to improve financial and other operational support for the Foundation and community, including the STF project and future development initiatives.

(also posted to GNOME Discourse, please head there if you have any questions or comments)

26 Apr 2024 10:39am GMT

It Happened Again.

I've been seeing a lot of ultra technical posts fly past my news feed lately and I'm tired of it. There's too much information out there, too many analyses of vague hardware capabilities, too much handwaving in the direction of compiler internals.

It's too much.

Take it out. I know you've got it with you. I know all my readers carry them at all times.

That's right.

It's time to make some pasta.

Everyone understands pasta.

Target Locked

Today I'll be firing up the pasta maker on this ticket that someone nerdsniped me with. This is the sort of simple problem that any of us smoothbrains can understand: app too slow.

Here at SGC, we're all experts at solving app too slow by now, so let's take a gander at the problem area.

I'm in a hurry to get to the gym today, so I'll skip over some of the less interesting parts of my analysis. Instead, let's look at some artisanal graphics.

This is an image, but let's pretend it's a graph of the time between when an app is started to when it displays its first frame:

At the start is when the user launched the app, the body of the arrow is what happens during "startup", and the head of the arrow is when the app has displayed its first frame to the user. The "startup" period is what the user perceives as latency. More technical blogs would break down here into discussions and navel-gazing about "time to first light" and "photon velocity" or whatever, but we're keeping things simple. If SwapBuffers is called, the app has displayed its frame.

Where are we at with this now?

Initial Findings

I did my testing on an Intel Icelake CPU/GPU because I'm lazy. Also because the original ticket was for Intel systems. Also because deal with it, this isn't an AMD blog.

The best way to time this is to:

• add an exit call at the end of SwapBuffers
• run the app in a while loop using time
• evaluate the results

On iris, the average startup time for gtk4-demo was between 190-200ms.

On zink, the average startup time was between 350-370ms.

Uh-oh.

More Graphics (The Fun Kind)

Initial analysis revealed something very stupid for the zink case: a lot of time was being spent on shaders.

Now, I'm not saying a lot of time was spent compiling shaders. That would be smart. Shaders have to be compiled, and it's not like that can be skipped or anything. A cold run of this app that compiles shaders takes upwards of 1.0 seconds on any driver, and I'm not looking to improve that case since it's rare. And hard. And also I gotta save some work for other people who want to make good blog posts.

The problem here is that when creating shaders, zink blocks while it does some initial shader rewrites and optimizations. This is like if you're going to make yourself a sandwich, before you put smoked brisket on the bread you have to first slice the bread so it's ready when you want to put the brisket on it. Sure, you could slice it after you've assembled your pile of pulled pork and slaw, but generally you slice the bread, you leave the bread sitting somewhere while you find/make/assemble the burnt ends for your sandwich, and then you finish making your sandwich. Compiling shaders is basically the same as making a sandwich.

But slicing bread takes time. And when you're slicing the bread, you're not doing anything else. You can't. You're holding a knife and a loaf of bread. You're physically incapable of doing anything else until you finish slicing.

Similarly, zink can't do anything else while it's doing that shader creation. It's sitting there creating the shaders. And while it's doing that, the rest of the app (or just the main GL thread if glthread is active) is blocked. It can't do anything else. It's waiting on zink to finish, and it cannot make forward progress until the shader creation has completed.

Now this process happens dozens or hundreds of times during app startup, and every time it happens, the app blocks. Its own initialization routines-reading configuration data, setting up global structs and signal handlers, making display server connections, etc-cannot proceed until GL stops blocking.

If you're unsure where I'm going with this, it's a bad thing that zink is slicing all this bread while the app is trying to make sandwiches.

Improvement

The year is whatever year you're reading this, and in that year we have very powerful CPUs. CPUs so powerful that you can do lots of things at once. Instead of having only two hands to hold the bread and slice it, you have your own hands and then the hands of another 10+ of your clones which are also able to hold bread and slice it. So if you tell one of those clones "slice some bread for me", you can do other stuff and come back to some nicely sliced bread. When exactly that bread arrives is another issue depensynchronizationding on how well you understand the joke here.

But this is me, so I get all the jokes, and that means I can do something like this:

By moving all that bread slicing into a thread, the rest of the startup operations can proceed without blocking. This frees up the app to continue with its own lengthy startup routines.

After the change, zink starts up in a average of 260-280ms, a 25% improvement.

I know not everyone wants pasta on their sandwiches, but that's where we ended up today.

Not The End

That changeset is the end of this post, but it's not the end of my investigation. There's still mysteries to uncover here.

Like why the farfalle is this app calling glXInitialize and eglInitialize?

Can zink get closer to iris's startup time?

We'll find out in a future installment of Who Wants To Eat Lunch?

25 Apr 2024 12:00am GMT