mic_none No sound detected from your microphone
Michael Meeks: 2024-03-31 Sunday
news.movim.eu / PlanetGnome • 31 March, 2024
Felix Häcker: #141 Sleek Documentation
news.movim.eu / PlanetGnome • 29 March, 2024 • 5 minutes
Update on what happened across the GNOME project in the week from March 22 to March 29.
Brage Fuglseth reports
This week Biblioteca was accepted into GNOME Circle. Biblioteca lets you browse and read GNOME documentation wherever you are in a sleek and convenient way. Congratulations!
Fast and secure file transfer.
Fina reports
Warp 0.7 has been released with QR Code scanning support 📸. This feature allows to initiate a file transfer just by scanning a code on the receiving device. Thanks a lot to GNOME Camera for providing the widgets for a modern camera stack. 🦀
Censor your private information on any image.
Bilal Elmoussaoui says
Obfuscate 0.0.10 is out. The app is now adaptive and shows a confirmation when closing the app with unsaved changes.
Follow your favorite blogs & news sites.
Jan Lukas announces
Newsflash 3.2 is out. Some highlights are:
- automatically scraping articles so you can read them offline
- editing feed URLs
- some performance improvements
You can read more here: https://blogs.gnome.org/jangernert/2024/03/25/newsflash-3-2/
A simple backup tool.
Michael Terry says
Déjà Dup Backups 46.beta is out. This adds modern Adwaita dialogs, now uses rclone for cloud support (rather than disparate Python libraries for each service), and adds various smaller UI improvements. Install the beta from flathub-beta (
flatpak install flathub-beta org.gnome.DejaDup) and please report any issues. Thanks!
A distraction free Markdown editor.
Manu reports
Since rendering random documents can be dangerous, this week I added a security feature to Apostrophe. It’ll offer the option to load potentially dangerous files with html and javascript deactivated. I also landed some patches that will unblock the last remaining issue that was preventing a GTK4 release: spellchecking. Hopefully I’ll be able to draft a stable release very soon. In the meantime betatesting is more than welcome. An updated build is already available on flathub-beta
d-k-bo announces
This week Televido received an update to use the new adaptive dialogs that were introduced in GNOME 46.
Televido is an app to access German-language public broadcasting live streams and archives based on APIs provided by the MediathekView project.
Since my first post here, it also got better mobile support, it supports downloading media using an external downloader such as Parabolic and the app is now available in English, German, Dutch and French.
ghani1990 says
Planify continues to evolve and enhance its user experience by introducing several exciting new features this week:
1. Quick Search Filters:
- Users can now efficiently filter tasks by various criteria directly from the Quick Search bar. These filters include:
- “Tomorrow” : To view tasks scheduled for the next day.
- “Untagged” : For tasks without specific tags.
- “Repeat” : To manage recurring tasks.
- “Anytime” : For tasks with no flexible deadlines.
2. Completed View in Sidebar:
- Users can easily access and review their completed tasks, streamlining the process of tracking progress.
These updates enhance Planify’s overall functionality and usability , making it an even more powerful and versatile tool for efficient task management.
Additionally, Planify has addressed several bugs and made performance improvements to ensure a smoother experience for users. 🚀📅🔍
Michael Terry says
Multiplication Puzzle 14.0 is out with modern Adwaita dialogs.
Browse the Fediverse.
Evangelos “GeopJr” Paterakis announces
Tuba 0.7 is now available, with many new features and bug fixes !
✨ Highlights:
- Filter handling and editing
- User and Post reporting
- Ported dialogs to
AdwDialogs- Tracking parameter stripping on paste
- Syntax highlighting
- Mutes & Blocks page
- Recently used emojis in the Custom Emoji Chooser
- Unread Announcements and Unreviewed Follow Requests banners
Matrix messaging app for GNOME written in Rust.
Kévin Commaille announces
Spring is here in Fractal land. Birds chirping, flowers blooming, and a new beta for you to try!
Staff’s picks for Fractal 7.beta:
- Encryption support has been extended, with server-side key backup and account recovery.
- Messages that failed to send can now be retried or discarded.
- Messages can be reported to server admins for moderation.
- Room details are now considered complete, with the addition of room address management, permissions, and version upgrade.
- A new member menu appears when clicking on an avatar in the room history. It offers a quick way to do many actions related to that person, including opening a direct chat with them and moderating them.
- Pills are clickable and allow to directly go to a room or member profile.
- Many more improvements on the accessibility front, for better navigability with a screen reader.
As usual, this release includes other improvements, fixes and new translations thanks to all our contributors, and our upstream projects.
It is available to install via Flathub Beta, see the instructions in our README .
As the version implies, there might be a slight risk of regressions, but it should be mostly stable. If all goes well the next step is the release candidate!
As always, you can try to fix one of our issues . Any help is greatly appreciated!
barthalion reports
To improve transparency, Flathub now shows an explicit “unverified” badge for community-maintained packages.
Meanwhile, I’ve been working on improving the configuration of our content delivery network. Mythic Beasts donated a new caching server, which will reduce the load on the origin server. I have enabled shielding in Fastly to further improve the cache hit ratio. I’m also looking into configuring Fastly to use segmented caching to resolve issues with installation of large applications.
psauberz announces
The Sovereign Tech Fund is designing a pilot program for a fellowship to support open source maintainers working on open digital infrastructure in the public interest. They are asking for input from maintainers in a survey on their blog . If you are a maintainer, please take ten minutes to respond to the survey by Sunday, 7 April 2024.
See you next week, and be sure to stop by #thisweek:gnome.org with updates on your own projects!
Christian Schaller: Fedora Workstation 40 – what are we working on
news.movim.eu / PlanetGnome • 28 March, 2024 • 7 minutes
So
Fedora Workstation 40 Beta has just come out
so I thought I share a bit about some of the things we are working on for Fedora Workstation currently and also major changes coming in from the community.
Flatpaks has been a key part of our strategy for desktop applications for a while now and we are working on a multitude of things to make Flatpaks an even stronger technology going forward. Christian Hergert is working on figuring out how applications that require system daemons will work with Flatpaks, using his own Sysprof project as the proof of concept application. The general idea here is to rely on the work that has happened in SystemD around sysext/confext/portablectl trying to figure out who we can get a system service installed from a Flatpak and the necessary bits wired up properly. The other part of this work, figuring out how to give applications permissions that today is handled with udev rules, that is being worked on by Hubert Figuière based on earlier work by Georges Stavracas on behalf of the GNOME Foundation thanks to the sponsorship from the Sovereign Tech Fund . So hopefully we will get both of these two important issues resolved soon. Kalev Lember is working on polishing up the Flatpak support in Foreman (and Satelitte) to ensure there are good tools for managing Flatpaks when you have a fleet of systems you manage, building on the work of Stephan Bergman. Finally Jan Horak and Jan Grulich is working hard on polishing up the experience of using Firefox from a fully sandboxed Flatpak. This work is mainly about working with the upstream community to get some needed portals over the finish line and polish up some UI issues in Firefox, like this one .
ToolbxToolbx , our project for handling developer containers, is picking up pace with Debarshi Ray currently working on getting full NVIDIA binary driver support for the containers. One of our main goals for Toolbx atm is making it a great tool for AI development and thus getting the NVIDIA & CUDA support squared of is critical. Debarshi has also spent quite a lot of time cleaning up the Toolbx website, providing easier access to and updating the documentation there. We are also moving to use the new Ptyxis (formerly Prompt) terminal application created by Christian Hergert, in Fedora Workstation 40. This both gives us a great GTK4 terminal, but we also believe we will be able to further integrate Toolbx and Ptyxis going forward, creating an even better user experience.
NovaSo as you probably know, we have been the core maintainers of the Nouveau project for years, keeping this open source upstream NVIDIA GPU driver alive. We plan on keep doing that, but the opportunities offered by the availability of the new GSP firmware for NVIDIA hardware means we should now be able to offer a full featured and performant driver. But co-hosting both the old and the new way of doing things in the same upstream kernel driver has turned out to be counter productive, so we are now looking to split the driver in two. For older pre-GSP NVIDIA hardware we will keep the old Nouveau driver around as is. For GSP based hardware we are launching a new driver called Nova . It is important to note here that Nova is thus not a competitor to Nouveau, but a continuation of it. The idea is that the new driver will be primarily written in Rust, based on work already done in the community, we are also evaluating if some of the existing Nouveau code should be copied into the new driver since we already spent quite a bit of time trying to integrate GSP there. Worst case scenario, if we can’t reuse code, we use the lessons learned from Nouveau with GSP to implement the support in Nova more quickly. Contributing to this effort from our team at Red Hat is Danilo Krummrich, Dave Airlie, Lyude Paul, Abdiel Janulgue and Phillip Stanner.
Explicit Sync and VRRAnother exciting development that has been a priority for us is explicit sync , which is critical for especially the NVidia driver, but which might also provide performance improvements for other GPU architectures going forward. So a big thank you to Michel Dänzer , Olivier Fourdan, Carlos Garnacho; and Nvidia folks, Simon Ser and the rest of community for working on this. This work has just finshed upstream so we will look at backporting it into Fedora Workstaton 40. Another major Fedora Workstation 40 feature is experimental support for Variable Refresh Rate or VRR in GNOME Shell. The feature was mostly developed by community member Dor Askayo, but Jonas Ådahl, Michel Dänzer, Carlos Garnacho and Sebastian Wick have all contributed with code reviews and fixes. In Fedora Workstation 40 you need to enable it using the command
gsettings set org.gnome.mutter experimental-features "['variable-refresh-rate']"
Already covered PipeWire in my post a week ago , but to quickly summarize here too. Using PipeWire for video handling is now finally getting to the stage where it is actually happening, both Firefox and OBS Studio now comes with PipeWire support and hopefully we can also get Chromium and Chrome to start taking a serious look at merging the patches for this soon. Whats more Wim spent time fixing Firewire FFADO bugs, so hopefully for our pro-audio community users this makes their Firewire equipment fully usable and performant with PipeWire. Wim did point out when I spoke to him though that the FFADO drivers had obviously never had any other consumer than JACK, so when he tried to allow for more functionality the drivers quickly broke down, so Wim has limited the featureset of the PipeWire FFADO module to be an exact match of how these drivers where being used by JACK. If the upstream kernel maintainer is able to fix the issues found by Wim then we could look at providing a more full feature set. In Fedora Workstation 40 the de-duplication support for v4l vs libcamera devices should work as soon as we update Wireplumber to the new 0.5 release.
To hear more about PipeWire and the latest developments be sure to check out this interview with Wim Taymans by the good folks over at Destination Linux.
Remote DesktopAnother major feature landing in Fedora Workstation 40 that Jonas Ådahl and Ray Strode has spent a lot of effort on is finalizing the remote desktop support for GNOME on Wayland. So there has been support for remote connections for already logged in sessions already, but with these updates you can do the login remotely too and thus the session do not need to be started already on the remote machine. This work will also enable 3rd party solutions to do remote logins on Wayland systems, so while I am not at liberty to mention names, be on the lookout for more 3rd party Wayland remoting software becoming available this year.
This work is also important to help Anaconda with its Wayland transition as remote graphical install is an important feature there. So what you should see there is Anaconda using GNOME Kiosk mode and the GNOME remote support to handle this going forward and thus enabling Wayland native Anaconda.
HDRAnother feature we been working on for a long time is HDR, or High Dynamic Range. We wanted to do it properly and also needed to work with a wide range of partners in the industry to make this happen. So over the last year we been contributing to improve various standards around color handling and acceleration to prepare the ground, work on and contribute to key libraries needed to for instance gather the needed information from GPUs and screens. Things are coming together now and Jonas Ådahl and Sebastian Wick are now going to focus on getting Mutter HDR capable, once that work is done we are by no means finished, but it should put us close to at least be able to start running some simple usecases (like some fullscreen applications) while we work out the finer points to get great support for running SDR and HDR applications side by side for instance.
PyTorchWe want to make Fedora Workstation a great place to do AI development and testing. First step in that effort is packaging up PyTorch and making sure it can have working hardware acceleration out of the box. Tom Rix has been leading that effort on our end and you will see the first fruits of that labor in Fedora Workstation 40 where PyTorch should work with GPU acceleration on AMD hardware (RockEM) out of the box. We hope and expect to be able to provide the same for NVIDIA and Intel graphics eventually too, but this is definitely a step by step effort.
Jordan Petridis: Thoughts on employing PGO and BOLT on the GNOME stack
news.movim.eu / PlanetGnome • 26 March, 2024 • 2 minutes
Christian was looking at PGO and BOLT
recently
I figured I’d write down my notes from the discussions we had on how we’d go about making things faster on our stack, since I don’t have time or the resource to pursue those plans myself atm.
First off let’s start with the basics, PGO (profile guided optimizations) and BOLT (Binary Optimization and Layout Tool) work in similar ways. You capture one or more “profiles” of a workload that’s representative of a usecase of your code and then the tools do their magic to make the common hot paths more efficient/cache-friendly/etc. Afterwards they produce a new binary that is hopefully faster than the old one and functionally identical so you can just replace it.
Now already we have two issues here that arise here:
First of all we don’t really have any benchmarks in our stack, let alone, ones that are rounded enough to account for the majority of usecases. Additionally we need better instrumentation to capture stats like frames, frame-times, and export them both for sysprof and so we can make the benchmark runners more useful.
Once we have the benchmarks we can use them to create the profiles for optimizations and to verify that any changes have the desired effect. We will need multiple profiles of all the different hardware/software configurations.
For example for GTK ideally we’d want to have a matrix of profiles for the different render backends (NGL/Vulkan) along with the mesa drivers they’d use depending on different hardware AMD/Intel and then also different architectures, so additional profile for Raspberrypi5 and Asahi stacks. We might also want to add a profile captured under qemu+virtio while we are it too.
Maintaining the benchmarks and profiles would be a lot of work and very tailored to each project so they would all have to live in their upstream repositories.
On the other hand, the optimization itself has to be done during the Tree/userland/OS composition and we’d have to aggregate all the profiles from all the projects to apply them. This is easily done when you are in control of the whole deployment as we can do for the GNOME Flatpak Runtime. It’s also easy to do if you are targeting an embedded deployment where most of the time you have custom images you are in full control off and know exactly the workload you will be running.
If we want distros to also apply these optimizations and for this to be done at scale, we’d have to make the whole process automatic and part of the usual compilation process so there would be no room for error during integration. The downside of this would be that we’d have a lot less opportunities for aggregating different usecases/profiles as projects would either have to own optimizations of the stack beneath them (ex: GTK being the one relinking pango) or only relink their own libraries.
To conclude, Post-linktime optimization would be a great avenue to explore as it seems to be one of the lower-hanging fruits when it comes to optimizing the whole stack. But it also would be quite the effort and require a decent amount of work to be committed to it. It would be worth it in the long run.
Andy Wingo: hacking v8 with guix, bis
news.movim.eu / PlanetGnome • 26 March, 2024 • 8 minutes
Good day, hackers. Today, a pragmatic note, on hacking on V8 from a Guix system.
I’m going to skip a lot of the background because, as it turns out, I wrote about this already almost a decade ago . But following that piece, I mostly gave up on doing V8 hacking from a Guix machine—it was more important to just go with the flow of the ever-evolving upstream toolchain. In fact, I ended up installing Ubuntu LTS on my main workstations for precisely this reason, which has worked fine; I still get Guix in user-space, which is better than nothing.
Since then, though, Guix has grown to the point that it’s easier to create an environment that can run a complicated upstream source management project like V8’s. This is mainly guix shell in the --container --emulate-fhs mode. This article is a step-by-step for how to get started with V8 hacking using Guix.
You would think this would be the easy part: just git clone the V8 source. But no, the build wants a number of other Google-hosted dependencies to be vendored into the source tree. To perform the initial fetch for those dependencies and to keep them up to date, you use helpers from the depot_tools project. You also use depot_tools to submit patches to code review.
When you live in the Guix world, you might be tempted to look into what depot_tools actually does, and to replicate its functionality in a more minimal, Guix-like way. Which, sure, perhaps this is a good approach for packaging V8 or Chromium or something, but when you want to work on V8, you need to learn some humility and just go with the flow. (It’s hard for the kind of person that uses Guix. But it’s what you do.)
You can make some small adaptations, though. depot_tools is mostly written in Python, and it actually bundles its own virtualenv support for using a specific python version. This isn’t strictly needed, so we can set the funny environment variable VPYTHON_BYPASS="manually managed python not supported by chrome operations" to just use python from the environment.
Sometimes depot_tools will want to run some prebuilt binaries. Usually on Guix this is anathema—we always build from source—but there’s only so much time in the day and the build system is not our circus, not our monkeys. So we get Guix to set up the environment using a container in --emulate-fhs mode; this lets us run third-party pre-build binaries. Note, these binaries are indeed free software! We can run them just fine if we trust Google, which you have to when working on V8.
Enough with the introduction. The first thing to do is to check out depot_tools .
mkdir src cd src git clone https://chromium.googlesource.com/chromium/tools/depot_tools.git
I’m assuming you have git in your Guix environment already.
Then you need to initialize depot_tools . For that you run a python script, which needs to run other binaries – so we need to make a specific environment in which it can run. This starts with a manifest of packages, is conventionally placed in a file named manifest.scm in the project’s working directory, though you don’t have one yet, so you can just write it into v8.scm or something anywhere:
(use-modules (guix packages)
(gnu packages gcc))
(concatenate-manifests
(list
(specifications->manifest
'(
"bash"
"binutils"
"clang-toolchain"
"coreutils"
"diffutils"
"findutils"
"git"
"glib"
"glibc"
"glibc-locales"
"grep"
"less"
"ld-gold-wrapper"
"make"
"nss-certs"
"nss-mdns"
"openssh"
"patch"
"pkg-config"
"procps"
"python"
"python-google-api-client"
"python-httplib2"
"python-pyparsing"
"python-requests"
"python-tzdata"
"sed"
"tar"
"wget"
"which"
"xz"
))
(packages->manifest
`((,gcc "lib")))))
Then, you guix shell -m v8.scm . But you actually do more than that, because we need to set up a container so that we can expose a standard /lib , /bin , and so on:
guix shell --container --network \ --share=$XDG_RUNTIME_DIR --share=$HOME \ --preserve=TERM --preserve=SSH_AUTH_SOCK \ --emulate-fhs \ --manifest=v8.scm
Let’s go through these options one by one.
--container : This is what lets us run pre-built binaries, because it uses Linux namespaces to remap the composed packages to /bin , /lib , and so on.
--network : Depot tools are going to want to download things, so we give them net access.
--share : By default, the container shares the current working directory with the “host”. But we need not only the checkout for V8 but also the sibling checkout for depot tools (more on this in a minute); let’s just share the whole home directory. Also, we share the /run/user/1000 directory, which is $XDG_RUNTIME_DIR , which lets us access the SSH agent, so we can check out over SSH.
--preserve : By default, the container gets a pruned environment. This lets us pass some environment variables through.
--emulate-fhs : The crucial piece that lets us bridge the gap between Guix and the world.
--manifest : Here we specify the list of packages to use when composing the environment.
We can use short arguments to make this a bit less verbose:
guix shell -CNF --share=$XDG_RUNTIME_DIR --share=$HOME \ -ETERM -ESSH_AUTH_SOCK -m manifest.scm
I would like it if all of these arguments could somehow be optional, that I could get a bare guix shell invocation to just apply them, when run in this directory. Perhaps some day.
Running guix shell like this drops you into a terminal. So let’s initialize depot tools:
cd $HOME/src export VPYTHON_BYPASS="manually managed python not supported by chrome operations" export PATH=$HOME/src/depot_tools:$PATH export SSL_CERT_DIR=/etc/ssl/certs/ export SSL_CERT_FILE=/etc/ssl/certs/ca-certificates.crt gclient
This should download a bunch of things, I don’t know what. But at this point we’re ready to go:
fetch v8
This checks out V8, which is about 1.3 GB, and then probably about as much again in dependencies.
You can build V8 directly:
# note caveat below! cd v8 tools/dev/gm.py x64.release
This will build fin... and then fail to link. The precise reason is obscure to me: it would seem that by default, V8 uses a whole Debian sysroot for Some Noble Purpose, and ends up linking against it. But it compiles against system glibc, which seems to have replaced fcntl64 with a versioned symbol, or some such nonsense. It smells like V8 built against a too-new glibc and then failed trying to link to an old glibc.
To fix this, you need to go into the args.gn that was generated in out/x64.release and then add use_sysroot = false , so that it links to system glibc instead of the downloaded one.
echo 'use_sysroot = false' >> out/x64.release/args.gn tools/dev/gm.py x64.release
You probably want to put the commands needed to set up your environment into some shell scripts. For Guix you could make guix-env :
#!/bin/sh guix shell -CNF --share=$XDG_RUNTIME_DIR --share=$HOME \ -ETERM -ESSH_AUTH_SOCK -m manifest.scm -- "$@"
Then inside the container you need to set the PATH and such, so we could put this into the V8 checkout as env :
#!/bin/sh # Look for depot_tools in sibling directory. depot_tools=`cd $(dirname $0)/../depot_tools && pwd` export PATH=$depot_tools:$PATH export VPYTHON_BYPASS="manually managed python not supported by chrome operations" export SSL_CERT_DIR=/etc/ssl/certs/ export SSL_CERT_FILE=/etc/ssl/certs/ca-certificates.crt exec "$@"
This way you can run ./guix-env ./env tools/dev/gm.py x64.release and not have to “enter” the container so much.
This all works fine enough, but I do have some meta-reflections.
I would prefer it if I didn’t have to use containers, for two main reasons. One is that the resulting build artifacts have to be run in the container, because they are dynamically linked to e.g. /lib , at least for the ELF loader. It would be better if I could run them on the host (with the host debugger, for example). Using Guix to make the container is better than e.g. docker, though, because I can ensure that the same tools are available in the guest as I use on the host. But also, I don’t like adding “modes” to my terminals: are you in or out of this or that environment. Being in a container is not like being in a vanilla guix shell , and that’s annoying.
The build process uses many downloaded tools and artifacts, including clang itself. This is a feature, in that I am using the same compiler that colleagues at Google use, which is important. But it’s also annoying and it would be nice if I could choose. (Having the same clang-format though is an absolute requirement.)
There are two tests failing, in this configuration. It is somehow related to time zones. I have no idea why, but I just ignore them.
If the build system were any weirder, I would think harder about maybe using Docker or something like that. Colleagues point to distrobox as being a useful wrapper. It is annoying though, because such a docker image becomes like a little stateful thing to do sysadmin work on, and I would like to avoid that if I can.
Welp, that’s all for today. Hopefully if you are contemplating installing Guix as your operating system (rather than just in user-space), this can give you a bit more information as to what it might mean when working on third-party projects. Happy hacking and until next time!
Jan Lukas Gernert: Newsflash 3.2
news.movim.eu / PlanetGnome • 26 March, 2024 • 2 minutes
Another small feature update just in time for gnome 46.
Lets start with something that already went into version 3.1.4: you can subscribe to feeds via CLI now. The idea is that this is a building block for seamlessly subscribing to websites from within a browser or something similar. Lets see how this develops further.
If Gitlab upvotes is a valid metric, this feature was the most requested one so far. Feed settings gained a new toggle to scrap the content of new articles. The sync will complete normally and in a second operation Newsflash tries to download the full content of all new articles in the background.
This is especially useful when there is no permanent internet connection. Now you can let Newsflash sync & download content while on WiFi and read the complete articles later even without an internet connection.
The local RSS backend gained the ability to update the URL where the feed is located (see the screenshot above). Sadly none of the other services support this via their APIs as far as I know.
The preferences dialog gained the ability to drop all old article and “vacuum” the database right away. Depending on the size of the database file this can take a few seconds, that’s why it is not done in the background during normal operations yet.
(btw: I’m not sure if I should keep the button as “destructive-action”)
Just a heads up that a lot of code managing the loading of the article list and keeping track of the displayed article and its state was refactored. If there are any regressions, please let me know.
Christian Hergerts constant stream of profiling blog posts finally got to me. So I fired up sysprof. Fully expecting to not be knowledgeable enough to draw any meaningful conclusions from the data. After all, the app is pretty snappy on my machine ™, so any improvements must be hard to find and even harder to solve. But much to my surprise about 30 minutes later two absolutely noticeable low hanging fruit performance problems were discovered and fixed.
So I encourage everyone to just try profiling your code. You may be surprised what you find.
Of course this release makes use of the new Adwaita Dialogs. For all the dialogs but one:
Configuring custom keybindings still spawns a new modal window. Multiple overlapping dialogs isn’t the greatest thing in the world. This and another annoying issue made me think about removing the feature from Newsflash completely.
The problem is that all shortcuts need to be disabled whenever the user is about to enter text. Otherwise the keybindings with a single letter cannot be entered as text.
All major feed readers (feedly, innoreader, etc) have a fixed set of cohesive keyboard shortcuts. I’ve been thinking about either having 2-3 shortcut configurations to choose from or just hard-coding keybindings all together.
I’d like to hear your thoughts. Do you use custom shortcuts? Would you be fine with a well thought out but hard-coded set of shortcuts? Would you prefer to choose from a few pre-defined shorcut configurations? Let me know, and help me find the best keybindings for all the actions that can be triggered via keyboard.
Christian Hergert: GNOME 45/46 Retrospective
news.movim.eu / PlanetGnome • 25 March, 2024 • 12 minutes
My creative work is more aligned to GNOME cycles than years. Now that GNOME 46 is is out it’s a good time to look back at some of the larger things I did during those cycles.
2023 kicked off with quite a kerfuffle around frame pointers.
Many people appear to have opinions on the topic though very few are aware of the trade-offs involved or the surface area of the problem domain. I spent quite some time writing articles to both educate and ultimately convince the Fedora council that enabling them is the single best thing they could do to help us make the operating system significantly faster release-to-release.
Much to my surprise both Ubuntu and Arch are choosing to follow.
Early this year I published an article in Fedora Magazine on the topic.
I still write a lot of C and have to integrate with a lot of C in my day to day work. Though I really miss asynchronous programming from other languages like when I was working on Mono all those years. Doing that sort of programming in C with the GObject stack was always painful due to the whole async/finish flow.
For decades we had other ways in C but none of them integrated well with GObject and come with their own sort of foot-guns.
So I put together libdex which could do futures/promises, fibers (including on threads), lock-free work-stealing among thread-pools, io_uring integration, asynchronous semaphores, channels, and more.
It’s really changed how I write C now especially with asychronous workflows. Being able to await on any number of futures which suspend your fiber is so handy. It reminds me a lot of the CCR library out of the Microsoft Robotic Labs way back when. I especially love that I can set up complex “if-these-or-that” style futures and await on them.
I think the part I’m most proud of is the global work queue for the thread-pool. Combining
eventfd
with
EFD_SEMAPHRE
and using io_uring worked extremely well and doesn’t suffer the thundering herd problem that you’d get if you did that with
poll()
or even
epoll()
. Being able to have work-stealing and a single worker wake up as something enters the global queue was not something I could do 20 years ago on Linux.
Where this advanced even further is that it was combined with a
GMainContext
on the worker threads. That too was not something that worked well in the past meaning that if you used threads you had to often forgo any sort of scheduled/repeated work.
Now that I was armed with actually functioning stack traces coming from the Linux perf subsystem it was time to beef up Sysprof.
Pretty much everything but the capture format was rewritten. Primarily because the way containers are constructed on Linux broke every assumption that profilers written 10 years ago had. Plus this was an opportunity to put
libdex
through its paces and it turned out great.
Correlating marks across GTK, GLib, and Mutter was extremely valuable.
Though the most valuable part is probably the addition of flamegraphs.
To test out the Sysprof rewrite I took a couple weeks to find and fix performance issues before the GNOME release. That uncovered a lot of unexpected performance issues in search providers. Fixes got in, CPU cycles were salvaged. Projects like Photos, Calculator, Characters, Nautilus, and libgweather are all performing well now it seems. I no longer find myself disabling search providers on new GNOME installations.
This work also caught JXL wallpapers adding double-digit seconds to our login time. That got pushed back a release while upstream improved GdkPixbuf loader performance.
Another little hidden memory stealer was
gnome-settings-daemon
because of all the isolated sub-daemons it starts. Each of these were parsing the default theme at startup which is fallout from the Meson build system handover. I had fixed this many years ago and now it works again to both save a small amount (maybe 1-3mb each) of memory for each process and reduced start-up time.
At one point I wanted to see what it would take to get Boxes on GTK 4. It seemed like one of the major impediments was a GTK 4 library to display as well as handle input (mouse, keyboard). That was something I worked on considerably in the past during my tenure at a large virtualization company so the problem domain is one I felt like I could contribute to.
I put together a prototype which led me to some interesting findings along the way.
Notably, both Qemu and the Linux kernel virtio_gpu drivers were not passing damage regions which prevented GTK from doing damage efficiently. I pointed out the offending code to both projects and now those are fixed. Now you can use the drm backend in a Qemu VM with VirGL and virtio_gpu and have minimal damage all the way through the host.
That work then got picked up by Bilal and Benjamin which has resulted in new APIs inside of GTK and consumed from libmks to further optimize damage regions.
Qemu however may still need to break it’s D-Bus API to properly pass DMA-BUF modifiers.
While working on Sysprof I ran into a number of issues with GtkExpression and GObject weak-ref safety. When you do as much threading as Sysprof does you’re bound to break things. Thankfully I had to deal with similar issues in Builder years ago so I took that knowledge to fix GtkExpression.
By combining both a GWeakRef and a GWeakNotify you can more safely track tertiary object disposal without races.
Also out of the Sysprof work came a lot flamegraphs showing various GType checking overhead. I spent some time diving in and caching the appropriate flags so that we save non-trivial percentage of CPU there.
My nearly decade desire to get rid of GSlice finally happened for most platforms. If you want really a really fast allocator that can do arenas well, I suggest looking into things like
tcmalloc
.
Also out of the Sysprof work came a discovery of systemd-oomd waking up to often and keeping my laptops from deeper sleep. That got fixed upstream in systemd.
One prototype I created was around documentation viewers and I’m using it daily now.
I want to search/browse documentation a bit differently than how devhelp and other documentation sites seem to work. It indexes everything into SQLite and manages that in terms of SDKs. Therefore things like cross-referencing between releases is trivial. Currently it can index your host, jhbuild, and any
org.gnome.Sdk.Docs
Flatpak SDK you’ve installed.
This too is built on libdex and Gom which allows for asynchronous SQLite using GObjects which are transparently inflated from the database.
Another fun bit of integration work was wrapping libflatpak in a Future-based API. Doing so made writing the miners and indexers much cleaner as they were not done inside of fibers.
A decade or more ago I made a library for automatically binding SQLite records to GObjects. I revamped it a bit so that it would play well with lazy loading of objects from a result set.
More recently it also saw significant performance improvements around how it utilizes the type system (a theme here I guess).
Writing an application like GNOME Builder is a huge amount of work. Some of that work is just scaffolding for what I lovingly consider Big Fucking Applications. Things like shortcut engines, menuing systems, action management, window groups and workspaces, panels, document grids, and more.
A bunch of that got extracted from Builder and put into libpanel.
Additionally I made it so that applications which use libpanel can still have modern GNOME sidebar styling. Builder uses this for its workspace windows in GNOME 46 and contributes to it’s modern look-and-feel.
One missing stair that was holding people back from porting their applications to GTK 4 was spellcheck. I already had a custom spellchecker for GNOME Text Editor and GNOME Builder which uses an augmented B+Tree I wrote years ago for range tracking.
That all was extracted into libspelling .
One of the harder parts to keep working in a Text Editor, strangely enough, is task cancellation. I took some time to get the details right so that even when closing tabs with documents loading we get those operations cancelled. The trickier bit is
GtkTextView
doing forward line validation and sizing.
But that all appears to work well now.
I also tweaked the overview map considerably to make things faster. You need to be extremely careful with widgets that produce so many render nodes which overlap complex clipping. Doubly so when you add fractional scaling and the border of a window can cross two pixels of the underlying display.
GNOME Builder got similar performance treatments.
While tracking down GTK renderer performance for GTK 4.14 I spent a lot of timing analyzing frame timings in Sysprof.
First, I noticed how Mutter was almost never dispatching events on time and mostly around 1 millisecond late. That got fixed with a
timerfd
patch to Mutter which tightens that up. At 120hz and higher that extra millisecond becomes extremely useful!
After fixing Mutter I went to the source and made patches taking two different strategies to see which was better. One used
timerfd
and the other using
ppoll()
. Ultimately, the
ppoll()
strategy was better and is now merged in GLib. That will tighten up every GLib-based application including the
GdkFrameClock
.
I also added support for the Wayland presentation-time protocol in GTK’s Wayland back-end so that predicted frame times are much more accurate.
In addition to the
ppoll()
work above in GLib I also did some work on speeding up how fast
GMainContext
can do an iteration of the main loop. We were doing extraneous
read()
on our
eventfd
each pass resulting in extra syscalls. I also optimized some GList traversals while I was there.
I separated the
GWeakRef
and
GWeakNotify
lists inside of GObject’s weak ref system so that we could rely on all pointers being cleared before user callback functions are executed. This predictability is essential for building safety at higher levels around weak references.
There were a few more cases in GtkSourceView that needed optimization. Some of them were simpler like premixing colors to avoid alpha blends on the GPU. In the end, applications like Text Editor should feel a lot snappier in GNOME 46 when combined with GTK 4.14.1 or newer.
I spent some time at the end of the 46 cycle aiding in the performance work on NGL/Vulkan. I tried to lend a hand based on the things I remember helping/hurting/doing nothing while working on the previous GL renderer. In all, I really like where the new NGL/Vulkan renderers are going.
While doing some of that work I realized that finalizing our expired cache entries of lines for the textview was reducing our chance at getting our frames submitted before their deadline. So a small patch later to defer that work until the end of the frame cycle helps considerably.
Another oddity that got fixed was that we were snapshotting textview child widgets (rarely used) twice in the GtkTextView thanks to an observant bug reporter. This improved the gutter rendering times for things like GtkSourceView.
I also tried to help define some of the GtkAccessibleText API so we can potentially be lazy from widget implementations. The goal here is to have zero overhead if you’re not using accessibility technology and still be fast if you are.
I also added a fast path for the old GL renderer for masked textures. But that never saw a release as the default renderer now that NGL is in place, so not such a big deal. It helped for Ptyxis/VTE while it lasted though.
GSK also so a bunch of little fixes to avoid hitting the type system so hard.
Libpeas got a major ABI bump which came with a lot of cleaning up of the ABI contracts. But even better, it got a GJS (SpiderMonkey) plugin loader for writing plugins in JavaScript.
GNOME Builder uses this for plugins now instead of PyGObject.
As my monitor resolution got higher my terminal interactivity in Builder was lessened. Especially while on Wayland. It got to the point that latency was causing me to miss-type frequently.
Thankfully, I had just finished work on Sysprof so I could take a look.
Builder is GTK 4 of course, and it turned out VTE was drawing with Cairo and therefore spending significant time on the CPU drawing and significant memory bandwidth uploading the full texture to the GPU each frame.
Something I did find funny was how up in arms people got about a prototype I wrote to find the theoretical upper bounds of PTY performance for a terminal emulator. How dare I do actual research before tackling a new problem domain for me.
In the end I finally figured out how to properly use
GskTextNode
directly with
PangoGlyphString
to avoid
PangoLayout
. A trick I’d use again in GtkSourceView to speed up line number drawing.
Along with modernizing the drawing stack in VTE I took the chance to optimize some of the cross-module performance issues. VTE performance is in pretty good shape today and will certainly get even better in it’s capable maintainers hands. They were extremely friendly and helpful to a newcomer showing up to their project with grand ideas of how to do things.
To validate all the VTE performance work I also ported the venerable GNOME Terminal to GTK 4. It wasn’t quite ready to ship in concert with GNOME 46 but I’m feeling good about it’s ability to ship during GNOME 47.
For years I had this prototype sitting around for a container-based terminal built on top of the Builder internals. I managed to extract that as part of my VTE performance work.
It’s a thing now, and it’s pretty good. I can’t imagine not using it day-to-day now.
Now that I have a GTK 4 terminal application to maintain the only responsible thing for me to do is to make sure that everyone can use it. So I wrote a new accessibility layer bridging VteTerminal to GtkAccessibleText in GTK.
While working on Ptyxis I realized that Podman was injecting an extra PTY into the mix. That makes foreground process tracking extremely difficult so I advocated the ability to remove it from Podman. That has now happened so in future versions of Ptyxis I plan to prod Podman into doing the right thing.
All sorts of nice little quality of life improvements happened in Builder. More control over the build pipeline and application runtime environment make it easier to integrate with odd systems and configurations.
The terminal work in Ptyxis came back into Builder so we got many paper cuts triaged. You’ll also notice many new color palettes that ship with Builder which were generated from palettes bundled with Ptyxis.
Memory usage has also been reduced even further.
I removed my social media accounts this year and it’s lovely. Cannot recommend it enough.
Christian Hergert: Debug Builds and GPUs
news.movim.eu / PlanetGnome • 24 March, 2024 • 1 minute
Decades ago, when you wanted to run debug builds for UI applications, things were incredibly slow.
First you’d wait minutes for the application to present a window. Then wait tens of seconds for each frame to render. You were extremely lucky if Valgrind caught the issue while you exercised the UI.
Things have gotten much better due to movement in two different directions.
In one direction GCC and Clang got compiler integration for sanitizers like ASAN. Instead of relying on extreme amounts of emulation in Valgrind compilers can insert the appropriate checks, canaries, and memory mapping tricks to catch all sorts of behavior.
In the other direction we’ve started drawing modern UI toolkits with the GPU. The idea here is that if the work is dispatched to the GPU, there is less for the CPU to run and therefore less work for the sanitizers and/or Valgrind to do.
Don’t let that fool you though. A lot of specialized work is done on the CPU still to allow those GPUs to go fast. You trade off framebuffer updates and huge memory bus transfers for more complex diffing, batching and reordering operations, state tracking, occasional texture uploads, and memory bandwidth for vertex buffers and the likes.
Here I’ve compiled all the hot parts of a GTK application with the address sanitizer. That includes GLib/GIO/GObject, Harfbuzz, Pango, and GTK. The application is also running with
GSK_DEBUG=full-redraw
to ensure we redraw the entire window every single frame with full damage. We use
GDK_DEBUG=no-vsync
to let it run as fast as it can rather than block waiting for the next vblank.
And still, GTK can produce hundreds of frames per second.
Truly magical.
Matthew Garrett: Digital forgeries are hard
news.movim.eu / PlanetGnome • 14 March, 2024 • 5 minutes • 3 visibility
Closing arguments in the trial between various people and
Craig Wright
over whether he's
Satoshi Nakamoto
are wrapping up today, amongst a bewildering array of presented evidence. But one utterly astonishing aspect of this lawsuit is that expert witnesses for
both
sides agreed that much of the digital evidence provided by Craig Wright was unreliable in one way or another, generally including indications that it wasn't produced at the point in time it claimed to be. And it's fascinating reading through the subtle (and, in some cases, not so subtle) ways that that's revealed.