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

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

26 Apr 2024 10:39am GMT

Let's go for my web review for the week 2024-17.

---

AI isn't useless. But is it worth it?

Tags: tech, ai, gpt, copilot, criticism, work

It is an interesting essay. It leans on the side of "assistants are useful for simple coding tasks" and it's a bit more critical when it's about writing. The stance is original I find, yes it can help with some writing tasks, but if you look at the writing tasks you can expedite this way… if you wish to expedite them isn't it a sign that they were providing little value in the first place? Is the solution the assistant or changing the way you work? Indeed this might hide some busy work otherwise.

https://www.citationneeded.news/ai-isnt-useless/

Magic Numbers | blarg

Tags: tech, networking, history

Interesting facts about how the ethernet frame MTU came to be 1500 bytes.

https://exple.tive.org/blarg/2024/04/24/magic-numbers/

Guiding users away from cd and ls :: Terminal Click - Bringing Dead Text to Life

Tags: tech, command-line, terminal

Interesting ideas for terminal emulators and shells. Maybe will make their way in other software.

https://terminal.click/posts/2024/04/guiding-users-away-from-cd-and-ls/

Tips on Adding JSON Output to Your CLI App - Brazil's Blog

Tags: tech, json, command-line

Nice set of advices. There are interesting things to do on the command line with more JSON output. It needs to be easy to work with though.

https://blog.kellybrazil.com/2021/12/03/tips-on-adding-json-output-to-your-cli-app/

Modern Linux mounts a lot of different types of virtual filesystems

Tags: tech, linux, filesystem

There is indeed a jungle of virtual filesystems nowadays. That doesn't make it easy to filter only for the "real" ones.

https://utcc.utoronto.ca/~cks/space/blog/linux/LinuxManyVirtualFilesystems

Shared libs, rpath and the runtime linker

Tags: tech, system, linux, linking, debugging

This can sometimes be confusing. Here are a couple of tips about debugging rpath and linker errors.

https://carlosrdrz.dev/shared-libs-rpath-and-the-runtime-linker

Coverage Guided Fuzzing - Extending Instrumentation to Hunt Down Bugs Faster! - Include Security Research Blog

Tags: tech, tests, security, fuzzing

Maybe a bit dry, but gives a good idea of how a fuzz testing harness works. And also how it can be tweaked.

https://blog.includesecurity.com/2024/04/coverage-guided-fuzzing-extending-instrumentation/

HTML attributes vs DOM properties - JakeArchibald.com

Tags: tech, html, web, frontend

There are differences between attributes on the HTML side and properties on the DOM side. This can quickly get confusing, here is a good reference for it.

https://jakearchibald.com/2024/attributes-vs-properties/

3 important things I overlooked during code reviews | Piglei

Tags: tech, codereview, programming

Indeed, naming, comments and communication styles are three aspects often overlooked during reviews. They are very important though and shouldn't be neglected.

https://www.piglei.com/articles/3-important-things-I-overlooked-during-cr/

First Come First Served: The Impact of File Position on Code Review

Tags: tech, codereview, cognition

I guess we kind of suspected it, this studies tends to prove it. Defects are more easily found in the first files of a code review rather than in the last ones.

https://arxiv.org/abs/2208.04259

Random musings on the Agile Manifesto - NeoPragma LLC

Tags: tech, agile, criticism

Interesting musings indeed. That's lesser heard opinions about the manifesto and its origins. Good food for thought.

https://neopragma.com/2024/04/random-musings-on-the-agile-manifesto/

Calculus Made Easy

Tags: mathematics, learning

I didn't know this book. It is written in a surprising style, but it's very much down to earth and to the point. For sure a good way to learn calculus.

https://calculusmadeeasy.org/

You Are What You Read, Even If You Don't Always Remember It - Jim Nielsen's Blog

Tags: reading, knowledge

Very good point. You might not remember the content, but if it impacted the way you think it did its job.

https://blog.jim-nielsen.com/2024/you-are-what-you-read/

---

Bye for now!

26 Apr 2024 10:37am GMT

Hotspot is a standalone GUI designed to provide a user-friendly interface for analyzing performance data. It takes a perf.data file, parses and evaluates its contents, and presents the results in a visually appealing and easily understandable manner. Our goal with Hotspot is to offer a modern alternative to perf report, making performance analysis on Linux systems more intuitive and efficient.

ChangeLog for Hotspot v1.5.0

It comes packed with a wealth of code cleanups, bug fixes and new functionality. Most notably, the disassembly view has been further improved with better searching, highlighting and faster performance.

Furthermore, we reworked the authentication mechanism to allow perf record to be run directly, with elevated priveleges, via pkexec, obsoleting the error prone old mechanism (see also https://nvd.nist.gov/vuln/detail/CVE-2023-28144).

We now also fully support Qt6 and KF6, while keeping compatibility with Qt5 and KF5. The AppImage below is still built with Qt5 but it might be the last time that we do this. The next version might become Qt6 only.

Many thanks to the various contributors who help build this software, both by writing code as well as reporting bugs.

To get a more detailed scope over all the changes in this new release, check out the full changelog on GitHub. More information about Hotspot can be obtained on its GitHub page or by watching this video.

Happy profiling everyone 🚀

The post Hotspot v1.5.0 released appeared first on KDAB.

26 Apr 2024 10:30am GMT

From last Friday to Wednesday I was in Berlin to attend the combined 2024 KDE Goals sprint that was graciously hosted by MBition. Compared to previous goals sprints where there were separate sprints Goal this year was different as all three happened at once in the same area. This allowed attendees to freely switch around the different topics and enables more collaboration opportunities. Lets see how that worked out for me.

Most of my time I actually spent in the context of the accessibility goal. I became part of a discussion of how QML comboboxes in general and the Kirigami Add-ons date picker is lacking in the accessibility departement. As the discussion went to how the default representation of a standard combobox could be improved, the question was raised if it would still be possible to do something special for customized comboboxes. This lead to prototyping on the date picker with the first approach being to forego the built in support in QtQuick and implement the relevant interfaces manually like one would do for QtWidgets. This was a lot of boring boilerplate code but it proved that this option is available for very specialized use cases. The solution we came up with in the end for our use cases was to provide the required properties and roles in a proxy Item that exposes the actual controls to the accessibility tools.

On the automatization front I was involved in creating two new CI checks. The first one is a reuse lint check that only checks new files for compliance which enables older projects to enforce coverage at least for new files. The second was an idea that came up during sprint that we could detect untranslated strings in QML files as these are usually to text properties. While it will never catch all cases during testing we found already some problematic cases in Plasma repositories. We discussed also some other points from the idea list such as a cherry-pick bot like the Qt Project uses and automatic updating the fix version field on bugzilla but these innocuous looking problems have some corner cases which require some more thought.

To the Sustainable Software goal I contributed the least. But together with Aleix and Joseph we debugged why the VNC setup of the KDE Eco Lab machine did not work anymore and fixed it. So in the end I interacted with all three goals.

The combined sprint was a nice experience and facilitated many discussion about the Goals but as always also about other KDE topics as is unavoidable when KDE community members are put together in a room. However I feel while it enabled people to jump around the different goals I am wary that in my opinion this setup removes a bit of focus from each goal compared to dedicated sprints.

Thanks to Mbition for hosting us and as a reminder your donations to KDE e.V make sprints such as these possible.

26 Apr 2024 9:15am 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

Progress

Yesterday I managed to implement in my open-source driver all the remaining operations so the SSDLite MobileDet model can run on Rockchip's NPU in the RK3588 SoC.

Performance is pretty good at 30 frames per second when using just one of the 3 cores that the NPU contains.

I uploaded the generated video to YouTube at:

Next steps

Now that we got to this level of usefulness, I'm going to switch to writing a kernel driver suited for inclusion into the Linux kernel, to the drivers/accel subsystem.

There is still lots of work to do, but progress is going pretty fast, though as I write more drivers for different NPUs I will have to split my time among them. At least, until we get more contributors! :)

19 Apr 2024 8:17am GMT