May 11, 2022

Christian SchallerWhy the open source driver release from NVIDIA is so important for Linux?

(Christian Schaller)

Today NVIDIA announced that they are releasing an open source kernel driver for their GPUs, so I want to share with you some background information and how I think this will impact Linux graphics and compute going forward.

One thing many people are not aware of is that Red Hat is the only Linux OS company who has a strong presence in the Linux compute and graphics engineering space. There are of course a lot of other people working in the space too, like engineers working for Intel, AMD and NVIDIA or people working for consultancy companies like Collabora or individual community members, but Red Hat as an OS integration company has been very active on trying to ensure we have a maintainable and shared upstream open source stack. This engineering presence is also what has allowed us to move important technologies forward, like getting hiDPI support for Linux some years ago, or working with NVIDIA to get glvnd implemented to remove a pain point for our users since the original OpenGL design only allowed for one OpenGl implementation to be installed at a time. We see ourselves as the open source community’s partner here, fighting to keep the linux graphics stack coherent and maintainable and as a partner for the hardware OEMs to work with when they need help pushing major new initiatives around GPUs for Linux forward. And as the only linux vendor with a significant engineering footprint in GPUs we have been working closely with NVIDIA. People like Kevin Martin, the manager for our GPU technologies team, Ben Skeggs the maintainer of Nouveau and Dave Airlie, the upstream kernel maintainer for the graphics subsystem, Nouveau contributor Karol Herbst and our accelerator lead Tom Rix have all taken part in meetings, code reviews and discussions with NVIDIA. So let me talk a little about what this release means (and also what it doesn’t mean) and what we hope to see come out of this long term.

First of all, what is in this new driver?
What has been released is an out of tree source code kernel driver which has been tested to support CUDA usecases on datacenter GPUs. There is code in there to support display, but it is not complete or fully tested yet. Also this is only the kernel part, a big part of a modern graphics driver are to be found in the firmware and userspace components and those are still closed source. But it does mean we have a NVIDIA kernel driver now that will start being able to consume the GPL-only APIs in the linux kernel, although this initial release doesn’t consume any APIs the old driver wasn’t already using. The driver also only supports NVIDIA Turing chip GPUs and newer, which means it is not targeting GPUs from before 2018. So for the average Linux desktop user, while this is a great first step and hopefully a sign of what is to come, it is not something you are going to start using tomorrow.

What does it mean for the NVidia binary driver?
Not too much immediately. This binary kernel driver will continue to be needed for older pre-Turing NVIDIA GPUs and until the open source kernel module is full tested and extended for display usecases you are likely to continue using it for your system even if you are on Turing or newer. Also as mentioned above regarding firmware and userspace bits and the binary driver is going to continue to be around even once the open source kernel driver is fully capable.

What does it mean for Nouveau?
Let me start with the obvious, this is actually great news for the Nouveau community and the Nouveau driver and NVIDIA has done a great favour to the open source graphics community with this release. And for those unfamiliar with Nouveau, Nouveau is the in-kernel graphics driver for NVIDIA GPUs today which was originally developed as a reverse engineered driver, but which over recent years actually have had active support from NVIDIA. It is fully functional, but is severely hampered by not having had the ability to for instance re-clock the NVIDIA card, meaning that it can’t give you full performance like the binary driver can. This was something we were working with NVIDIA trying to remedy, but this new release provides us with a better path forward. So what does this new driver mean for Nouveau? Less initially, but a lot in the long run. To give a little background first. The linux kernel does not allow multiple drivers for the same hardware, so in order for a new NVIDIA kernel driver to go in the current one will have to go out or at least be limited to a different set of hardware. The current one is Nouveau. And just like the binary driver a big chunk of Nouveau is not in the kernel, but are the userspace pieces found in Mesa and the Nouveau specific firmware that NVIDIA currently kindly makes available. So regardless of the long term effort to create a new open source in-tree kernel driver based on this new open source driver for NVIDIA hardware, Nouveau will very likely be staying around to support pre-turing hardware just like the NVIDIA binary kernel driver will.

The plan we are working towards from our side, but which is likely to take a few years to come to full fruition, is to come up with a way for the NVIDIA binary driver and Mesa to share a kernel driver. The details of how we will do that is something we are still working on and discussing with our friends at NVIDIA to address both the needs of the NVIDIA userspace and the needs of the Mesa userspace. Along with that evolution we hope to work with NVIDIA engineers to refactor the userspace bits of Mesa that are now targeting just Nouveau to be able to interact with this new kernel driver and also work so that the binary driver and Nouveau can share the same firmware. This has clear advantages for both the open source community and the NVIDIA. For the open source community it means that we will now have a kernel driver and firmware that allows things like changing the clocking of the GPU to provide the kind of performance people expect from the NVIDIA graphics card and it means that we will have an open source driver that will have access to the firmware and kernel updates from day one for new generations of NVIDIA hardware. For the ‘binary’ driver, and I put that in ” signs because it will now be less binary :), it means as stated above that it can start taking advantage of the GPL-only APIs in the kernel, distros can ship it and enable secure boot, and it gets an open source consumer of its kernel driver allowing it to go upstream.
If this new shared kernel driver will be known as Nouveau or something completely different is still an open question, and of course it happening at all depends on if we and the rest of the open source community and NVIDIA are able to find a path together to make it happen, but so far everyone seems to be of good will.

What does this release mean for linux distributions like Fedora and RHEL?

Over time it provides a pathway to radically simplify supporting NVIDIA hardware due to the opportunities discussed elsewhere in this document. Long term we will hope be able to get a better user experience with NVIDIA hardware in terms out of box functionality. Which means day 1 support for new chipsets, a high performance open source Mesa driver for NVIDIA and it will allow us to sign the NVIDIA driver alongside the rest of the kernel to enable things like secureboot support. Since this first release is targeting compute one can expect that these options will first be available for compute users and then graphics at a later time.

What are the next steps
Well there is a lot of work to do here. NVIDIA need to continue the effort to make this new driver feature complete for both Compute and Graphics Display usecases, we’d like to work together to come up with a plan for what the future unified kernel driver can look like and a model around it that works for both the community and NVIDIA, we need to add things like a Mesa Vulkan driver. We at Red Hat will be playing an active part in this work as the only Linux vendor with the capacity to do so and we will also work to ensure that the wider open source community has a chance to participate fully like we do for all open source efforts we are part of.

If you want to hear more about this I did talk with Chris Fisher and Linux Action News about this topic. Note: I did state some timelines in that interview which I didn’t make clear was my guesstimates and not in any form official NVIDIA timelines, so apologize for the confusion.

by uraeus at May 11, 2022 07:52 PM

May 09, 2022

Robert McQueenEvolving a strategy for 2022 and beyond

(Robert McQueen)

As a board, we have been working on several initiatives to make the Foundation a better asset for the GNOME Project. We’re working on a number of threads in parallel, so I wanted to explain the “big picture” a bit more to try and connect together things like the new ED search and the bylaw changes.

We’re all here to see free and open source software succeed and thrive, so that people can be be truly empowered with agency over their technology, rather than being passive consumers. We want to bring GNOME to as many people as possible so that they have computing devices that they can inspect, trust, share and learn from.

In previous years we’ve tried to boost the relevance of GNOME (or technologies such as GTK) or solicit donations from businesses and individuals with existing engagement in FOSS ideology and technology. The problem with this approach is that we’re mostly addressing people and organisations who are already supporting or contributing FOSS in some way. To truly scale our impact, we need to look to the outside world, build better awareness of GNOME outside of our current user base, and find opportunities to secure funding to invest back into the GNOME project.

The Foundation supports the GNOME project with infrastructure, arranging conferences, sponsoring hackfests and travel, design work, legal support, managing sponsorships, advisory board, being the fiscal sponsor of GNOME, GTK, Flathub… and we will keep doing all of these things. What we’re talking about here are additional ways for the Foundation to support the GNOME project – we want to go beyond these activities, and invest into GNOME to grow its adoption amongst people who need it. This has a cost, and that means in parallel with these initiatives, we need to find partners to fund this work.

Neil has previously talked about themes such as education, advocacy, privacy, but we’ve not previously translated these into clear specific initiatives that we would establish in addition to the Foundation’s existing work. This is all a work in progress and we welcome any feedback from the community about refining these ideas, but here are the current strategic initiatives the board is working on. We’ve been thinking about growing our community by encouraging and retaining diverse contributors, and addressing evolving computing needs which aren’t currently well served on the desktop.

Initiative 1. Welcoming newcomers. The community is already spending a lot of time welcoming newcomers and teaching them the best practices. Those activities are as time consuming as they are important, but currently a handful of individuals are running initiatives such as GSoC, Outreachy and outreach to Universities. These activities help bring diverse individuals and perspectives into the community, and helps them develop skills and experience of collaborating to create Open Source projects. We want to make those efforts more sustainable by finding sponsors for these activities. With funding, we can hire people to dedicate their time to operating these programs, including paid mentors and creating materials to support newcomers in future, such as developer documentation, examples and tutorials. This is the initiative that needs to be refined the most before we can turn it into something real.

Initiative 2: Diverse and sustainable Linux app ecosystem. I spoke at the Linux App Summit about the work that GNOME and Endless has been supporting in Flathub, but this is an example of something which has a great overlap between commercial, technical and mission-based advantages. The key goal here is to improve the financial sustainability of participating in our community, which in turn has an impact on the diversity of who we can expect to afford to enter and remain in our community. We believe the existence of this is critically important for individual developers and contributors to unlock earning potential from our ecosystem, through donations or app sales. In turn, a healthy app ecosystem also improves the usefulness of the Linux desktop as a whole for potential users. We believe that we can build a case for commercial vendors in the space to join an advisory board alongside with GNOME, KDE, etc to input into the governance and contribute to the costs of growing Flathub.

Initiative 3: Local-first applications for the GNOME desktop. This is what Thib has been starting to discuss on Discourse, in this thread. There are many different threats to free access to computing and information in today’s world. The GNOME desktop and apps need to give users convenient and reliable access to technology which works similarly to the tools they already use everyday, but keeps them and their data safe from surveillance, censorship, filtering or just being completely cut off from the Internet. We believe that we can seek both philanthropic and grant funding for this work. It will make GNOME a more appealing and comprehensive offering for the many people who want to protect their privacy.

The idea is that these initiatives all sit on the boundary between the GNOME community and the outside world. If the Foundation can grow and deliver these kinds of projects, we are reaching to new people, new contributors and new funding. These contributions and investments back into GNOME represent a true “win-win” for the newcomers and our existing community.

(Originally posted to GNOME Discourse, please feel free to join the discussion there.)

by ramcq at May 09, 2022 02:01 PM

May 02, 2022

GStreamerGStreamer 1.20.2 stable bug fix release


The GStreamer team is pleased to announce the second bug fix release in the stable 1.20 release series of your favourite cross-platform multimedia framework!

This release only contains bugfixes and it should be safe to update from 1.20.x.

Highlighted bugfixes:

  • avviddec: Remove vc1/wmv3 override and fix crashes on WMV files with FFMPEG 5.0+
  • macOS: fix plugin discovery for GStreamer installed via brew and fix loading of Rust plugins
  • rtpbasepayload: various header extension handling fixes
  • rtpopusdepay: fix regression in stereo input handling if sprop-stereo is not advertised
  • rtspclientsink: fix possible shutdown deadlock
  • mpegts: gracefully handle "empty" program maps and fix AC-4 detection
  • mxfdemux: Handle empty VANC packets and fix EOS handling
  • playbin3: various playbin3, uridecodebin3, and playsink fixes
  • ptpclock: fix initial sync-up with certain devices
  • gltransformation: let graphene alloc its structures memory aligned
  • webrtcbin fixes and webrtc sendrecv example improvements
  • video4linux2: various fixes including some fixes for Raspberry Pi users
  • videorate segment handling fixes and other fixes
  • nvh264dec, nvh265dec: Fix broken key-unit trick modes and reverse playback
  • wpe: Reintroduce persistent WebContext
  • cerbero: Make it easier to consume 1.20.1 macOS GStreamer .pkgs
  • build fixes and gobject annotation fixes
  • bug fixes, security fixes, memory leak fixes, and other stability and reliability improvements

See the GStreamer 1.20.2 release notes for more details.

Binaries for Android, iOS, macOS and Windows will be available shortly.

Release tarballs can be downloaded directly here:

May 02, 2022 11:30 PM

Sebastian DrögeInstantaneous RTP synchronization & retrieval of absolute sender clock times with GStreamer

(Sebastian Dröge)

Over the last few weeks, GStreamer’s RTP stack got a couple of new and quite useful features. As it is difficult to configure, mostly because there being so many different possible configurations, I decided to write about this a bit with some example code.

The features are RFC 6051-style rapid synchronization of RTP streams, which can be used for inter-stream (e.g. audio/video) synchronization as well as inter-device (i.e. network) synchronization, and the ability to easily retrieve absolute sender clock times per packet on the receiver side.

Note that each of this was already possible before with GStreamer via different mechanisms with different trade-offs. Obviously, not being able to have working audio/video synchronization would be simply not acceptable and I previously talked about how to do inter-device synchronization with GStreamer before, for example at the GStreamer Conference 2015 in Düsseldorf.

The example code below will make use of the GStreamer RTSP Server library but can be applied to any kind of RTP workflow, including WebRTC, and are written in Rust but the same can also be achieved in any other language. The full code can be found in this repository.

And for reference, the merge requests to enable all this are [1], [2] and [3]. You probably don’t want to backport those to an older version of GStreamer though as there are dependencies on various other changes elsewhere. All of the following needs at least GStreamer from the git main branch as of today, or the upcoming 1.22 release.

Baseline Sender / Receiver Code

The starting point of the example code can be found here in the baseline branch. All the important steps are commented so it should be relatively self-explanatory.


The sender is starting an RTSP server on the local machine on port 8554 and provides a media with H264 video and Opus audio on the mount point /test. It can be started with

$ cargo run -p rtp-rapid-sync-example-send

After starting the server it can be accessed via GStreamer with e.g. gst-play-1.0 rtsp:// or similarly via VLC or any other software that supports RTSP.

This does not do anything special yet but lays the foundation for the following steps. It creates an RTSP server instance with a custom RTSP media factory, which in turn creates custom RTSP media instances. All this is not needed at this point yet but will allow for the necessary customization later.

One important aspect here is that the base time of the media’s pipeline is set to zero


This allows the timeoverlay element that is placed in the video part of the pipeline to render the clock time over the video frames. We’re going to use this later to confirm on the receiver that the clock time on the sender and the one retrieved on the receiver are the same.

let video_overlay = gst::ElementFactory::make("timeoverlay", None)
    .context("Creating timeoverlay")?;
video_overlay.set_property_from_str("time-mode", "running-time");

It actually only supports rendering the running time of each buffer, but in a live pipeline with the base time set to zero the running time and pipeline clock time are the same. See the documentation for some more details about the time concepts in GStreamer.

Overall this creates the following RTSP stream producer bin, which will be used also in all the following steps:


The receiver is a simple playbin pipeline that plays an RTSP URI given via command-line parameters and runs until the stream is finished or an error has happened.

It can be run with the following once the sender is started

$ cargo run -p rtp-rapid-sync-example-send -- "rtsp://"

Please don’t forget to replace the IP with the IP of the machine that is actually running the server.

All the code should be familiar to anyone who ever wrote a GStreamer application in Rust, except for one part that might need a bit more explanation

    glib::closure!(|_playbin: &gst::Pipeline, source: &gst::Element| {
        source.set_property("latency", 40u32);

playbin is going to create an rtspsrc, and at that point it will emit the source-setup signal so that the application can do any additional configuration of the source element. Here we’re connecting a signal handler to that signal to do exactly that.

By default rtspsrc introduces a latency of 2 seconds of latency, which is a lot more than what is usually needed. For live, non-VOD RTSP streams this value should be around the network jitter and here we’re configuring that to 40 milliseconds.

Retrieval of absolute sender clock times

Now as the first step we’re going to retrieve the absolute sender clock times for each video frame on the receiver. They will be rendered by the receiver at the bottom of each video frame and will also be printed to stdout. The changes between the previous version of the code and this version can be seen here and the final code here in the sender-clock-time-retrieval branch.

When running the sender and receiver as before, the video from the receiver should look similar to the following

The upper time that is rendered on the video frames is rendered by the sender, the bottom time is rendered by the receiver and both should always be the same unless something is broken here. Both times are the pipeline clock time when the sender created/captured the video frame.

In this configuration the absolute clock times of the sender are provided to the receiver via the NTP / RTP timestamp mapping provided by the RTCP Sender Reports. That’s also the reason why it takes about 5s for the receiver to know the sender’s clock time as RTCP packets are not scheduled very often and only after about 5s by default. The RTCP interval can be configured on rtpbin together with many other things.


On the sender-side the configuration changes are rather small and not even absolutely necessary.

rtpbin.set_property_from_str("ntp-time-source", "clock-time");

By default the RTP NTP time used in the RTCP packets is based on the local machine’s walltime clock converted to the NTP epoch. While this works fine, this is not the clock that is used for synchronizing the media and as such there will be drift between the RTP timestamps of the media and the NTP time from the RTCP packets, which will be reset every time the receiver receives a new RTCP Sender Report from the sender.

Instead, we configure rtpbin here to use the pipeline clock as the source for the NTP timestamps used in the RTCP Sender Reports. This doesn’t give us (by default at least, see later) an actual NTP timestamp but it doesn’t have the drift problem mentioned before. Without further configuration, in this pipeline the used clock is the monotonic system clock.

rtpbin.set_property("rtcp-sync-send-time", false);

rtpbin normally uses the time when a packet is sent out for the NTP / RTP timestamp mapping in the RTCP Sender Reports. This is changed with this property to instead use the time when the video frame / audio sample was captured, i.e. it does not include all the latency introduced by encoding and other processing in the sender pipeline.

This doesn’t make any big difference in this scenario but usually one would be interested in the capture clock times and not the send clock times.


On the receiver-side there are a few more changes. First of all we have to opt-in to rtpjitterbuffer putting a reference timestamp metadata on every received packet with the sender’s absolute clock time.

    glib::closure!(|_playbin: &gst::Pipeline, source: &gst::Element| {
        source.set_property("latency", 40u32);
        source.set_property("add-reference-timestamp-meta", true);

rtpjitterbuffer will start putting the metadata on packets once it knows the NTP / RTP timestamp mapping, i.e. after the first RTCP Sender Report is received in this case. Between the Sender Reports it is going to interpolate the clock times. The normal timestamps (PTS) on each packet are not affected by this and are still based on whatever clock is used locally by the receiver for synchronization.

To actually make use of the reference timestamp metadata we add a timeoverlay element as video-filter on the receiver:

let timeoverlay =
    gst::ElementFactory::make("timeoverlay", None).context("Creating timeoverlay")?;

timeoverlay.set_property_from_str("time-mode", "reference-timestamp");
timeoverlay.set_property_from_str("valignment", "bottom");

pipeline.set_property("video-filter", &timeoverlay);

This will then render the sender’s absolute clock times at the bottom of each video frame, as seen in the screenshot above.

And last we also add a pad probe on the sink pad of the timeoverlay element to retrieve the reference timestamp metadata of each video frame and then printing the sender’s clock time to stdout:

let sinkpad = timeoverlay
    .expect("Failed to get timeoverlay sinkpad");
    .add_probe(gst::PadProbeType::BUFFER, |_pad, info| {
        if let Some(gst::PadProbeData::Buffer(ref buffer)) = {
            if let Some(meta) = buffer.meta::<gst::ReferenceTimestampMeta>() {
                println!("Have sender clock time {}", meta.timestamp());
            } else {
                println!("Have no sender clock time");

    .expect("Failed to add pad probe");

Rapid synchronization via RTP header extensions

The main problem with the previous code is that the sender’s clock times are only known once the first RTCP Sender Report is received by the receiver. There are many ways to configure rtpbin to make this happen faster (e.g. by reducing the RTCP interval or by switching to the AVPF RTP profile) but in any case the information would be transmitted outside the actual media data flow and it can’t be guaranteed that it is actually known on the receiver from the very first received packet onwards. This is of course not a problem in every use-case, but for the cases where it is there is a solution for this problem.

RFC 6051 defines an RTP header extension that allows to transmit the NTP timestamp that corresponds an RTP packet directly together with this very packet. And that’s what the next changes to the code are making use of.

The changes between the previous version of the code and this version can be seen here and the final code here in the rapid-synchronization branch.


To add the header extension on the sender-side it is only necessary to add an instance of the corresponding header extension implementation to the payloaders.

let hdr_ext = gst_rtp::RTPHeaderExtension::create_from_uri(
    .context("Creating NTP 64-bit RTP header extension")?;
video_pay.emit_by_name::<()>("add-extension", &[&hdr_ext]);

This first instantiates the header extension based on the uniquely defined URI for it, then sets its ID to 1 (see RFC 5285) and then adds it to the video payloader. The same is then done for the audio payloader.

By default this will add the header extension to every RTP packet that has a different RTP timestamp than the previous one. In other words: on the first packet that corresponds to an audio or video frame. Via properties on the header extension this can be configured but generally the default should be sufficient.


On the receiver-side no changes would actually be necessary. The use of the header extension is signaled via the SDP (see RFC 5285) and it will be automatically made use of inside rtpbin as another source of NTP / RTP timestamp mappings in addition to the RTCP Sender Reports.

However, we configure one additional property on rtpbin

    glib::closure!(|_rtspsrc: &gst::Element, rtpbin: &gst::Element| {
        rtpbin.set_property("min-ts-offset", gst::ClockTime::from_mseconds(1));

Inter-stream audio/video synchronization

The reason for configuring the min-ts-offset property on the rtpbin is that the NTP / RTP timestamp mapping is not only used for providing the reference timestamp metadata but it is also used for inter-stream synchronization by default. That is, for getting correct audio / video synchronization.

With RTP alone there is no mechanism to synchronize multiple streams against each other as the packet’s RTP timestamps of different streams have no correlation to each other. This is not too much of a problem as usually the packets for audio and video are received approximately at the same time but there’s still some inaccuracy in there.

One approach to fix this is to use the NTP / RTP timestamp mapping for each stream, either from the RTCP Sender Reports or from the RTP header extension, and that’s what is made use of here. And because the mapping is provided very often via the RTP header extension but the RTP timestamps are only accurate up to clock rate (1/90000s for video and 1/48000s) for audio in this case, we configure a threshold of 1ms for adjusting the inter-stream synchronization. Without this it would be adjusted almost continuously by a very small amount back and forth.

Other approaches for inter-stream synchronization are provided by RTSP itself before streaming starts (via the RTP-Info header), but due to a bug this is currently not made use of by GStreamer.

Yet another approach would be via the clock information provided by RFC 7273, about which I already wrote previously and which is also supported by GStreamer. This also allows inter-device, network synchronization and used for that purpose as part of e.g. AES67, Ravenna, SMPTE 2022 / 2110 and many other protocols.

Inter-device network synchronization

Now for the last part, we’re going to add actual inter-device synchronization to this example. The changes between the previous version of the code and this version can be seen here and the final code here in the network-sync branch. This does not use the clock information provided via RFC 7273 (which would be another option) but uses the same NTP / RTP timestamp mapping that was discussed above.

When starting the receiver multiple times on different (or the same) machines, each of them should play back the media synchronized to each other and exactly 2 seconds after the corresponding audio / video frames are produced on the sender.

For this, both sender and all receivers are using an NTP clock ( in this case) instead of the local monotonic system clock for media synchronization (i.e. as the pipeline clock). Instead of an NTP clock it would also be possible to any other mechanism for network clock synchronization, e.g. PTP or the GStreamer netclock.

println!("Syncing to NTP clock");
    .context("Syncing NTP clock")?;
println!("Synced to NTP clock");

This code instantiates a GStreamer NTP clock and then synchronously waits up to 5 seconds for it to synchronize. If that fails then the application simply exits with an error.


On the sender side all that is needed is to configure the RTSP media factory, and as such the pipeline used inside it, to use the NTP clock


This causes all media inside the sender’s pipeline to be synchronized according to this NTP clock and to also use it for the NTP timestamps in the RTCP Sender Reports and the RTP header extension.


On the receiver side the same has to happen


In addition a couple more settings have to be configured on the receiver though. First of all we configure a static latency of 2 seconds on the receiver’s pipeline.


This is necessary as GStreamer can’t know the latency of every receiver (e.g. different decoders might be used), and also because the sender latency can’t be automatically known. Each audio / video frame will be timestamped on the receiver with the NTP timestamp when it was captured / created, but since then all the latency of the sender, the network and the receiver pipeline has passed and for this some compensation must happen.

Which value to use here depends a lot on the overall setup, but 2 seconds is a (very) safe guess in this case. The value only has to be larger than the sum of sender, network and receiver latency and in the end has the effect that the receiver is showing the media exactly that much later than the sender has produced it.

And last we also have to tell rtpbin that

  1. sender and receiver clock are synchronized to each other, i.e. in this case both are using exactly the same NTP clock, and that no translation to the pipeline’s clock is necessary, and
  2. that the outgoing timestamps on the receiver should be exactly the sender timestamps and that this conversion should happen based on the NTP / RTP timestamp mapping

source.set_property_from_str("buffer-mode", "synced");
source.set_property("ntp-sync", true);

And that’s it.

A careful reader will also have noticed that all of the above would also work without the RTP header extension, but then the receivers would only be synchronized once the first RTCP Sender Report is received. That’s what the test-netclock.c / test-netclock-client.c example from the GStreamer RTSP server is doing.

As usual with RTP, the above is by far not the only way of doing this and GStreamer also supports various other synchronization mechanisms. Which one is the correct one for a specific use-case depends on a lot of factors.

by slomo at May 02, 2022 01:00 PM

Víctor JáquezFrom gst-build to local-projects

Two years ago I wrote a blog post about using gst-build inside of WebKit SDK flatpak. Well, all that has changed. That’s the true upstream spirit.

There were two main reason for the change:

  1. Since the switch to GStreamer mono repository, gst-build has been deprecated. The mechanism in WebKit were added, basically, to allow GStreamer upstream, so keeping gst-build directory just polluted the conceptual framework.
  2. By using gst-build one could override almost any other package in WebKit SDK. For example, for developing gamepad handling in WPE I added libmanette as a GStreamer subproject, to link a modified version of the library rather than the one in flatpak. But that approach added an unneeded conceptual depth in tree.

In order to simplify these operations, by taking advantage of Meson’s subproject support directly, gst-build handling were removed and new mechanism was set in place: Local Dependencies. With local dependencies, you can add or override almost any dependency, while flatting the tree layout, by placing at the same level GStreamer and any other library. Of course, in order add dependencies, they must be built with meson.

For example, to override libsoup and GStreamer, just clone both repositories below of Tools/flatpak/local-projects/subprojects, and declare them in WEBKIT_LOCAL_DEPS environment variable:

$ export WEBKIT_SDK_LOCAL_DEPS=libsoup,gstreamer-full
$ export WEBKIT_SDK_LOCAL_DEPS_OPTIONS="-Dgstreamer-full:introspection=disabled -Dgst-plugins-good:soup=disabled"
$ build-webkit --wpe

by vjaquez at May 02, 2022 11:11 AM

April 25, 2022

Sebastian Pölsterlscikit-survival 0.17.2 released

I’m pleased to announce the release of scikit-survival 0.17.2. This release fixes several small issues with packaging scikit-survival and the documentation. For a full list of changes in scikit-survival 0.17.2, please see the release notes.

Most notably, binary wheels are now available for Linux, Windows, and macOS (Intel). This has been possible thanks to the cibuildwheel build tool, which makes it incredible easy to use GitHub Actions for building those wheels for multiple versions of Python. Therefore, you can now use pip without building everything from source by simply running

pip install scikit-survival

As before, pre-built conda packages are available too, by running

 conda install -c sebp scikit-survival

Support for Apple Silicon M1

Currently, there are no pre-built packages for Mac with Apple Silicon M1 hardware (also known as macos/arm64). There are two main reasons for that. The biggest problem is the lack of CI servers that run on Apple Silicon M1. This makes it difficult to systematically test scikit-survival on such hardware. Second, some of scikit-survival’s dependencies do not offer wheels for macos/arm64 yet, namely ecos and osqp.

However, conda-forge figured out a way to cross-compile packages, and do offer scikit-survival for macos/arm64. I tried to adapt their conda recipe, but failed to achieve a working cross-compilation process so far. Cross-compiling with cibuildwheel would be an alternative, but currently doesn’t make much sense if run-time dependencies ecos and osqp do not provide wheels for macos/arm64. I hope these issues can be resolved in the near future.

April 25, 2022 06:14 PM

April 20, 2022

Thomas Vander SticheleRunning Anthos inside Google

(Thomas Vander Stichele)

"With everyone and their dog shifting to containers, and away from virtual machines (VMs), we realized that running vendor-provided software on VMs at Google was slowing us down. So we moved."

Bikram co-authored this blog post last year about DASInfra's experience moving workloads from Corp to Anthos. The group I run at work is going down a similar path by migrating VMs to Anthos on bare metal for on-prem.

Taken from The Playlist - a curated perspective on the intersection of form and content (subscribe, discuss)

flattr this!

by Thomas at April 20, 2022 08:40 PM

April 18, 2022

Thomas Vander SticheleWhat’s the next action?

(Thomas Vander Stichele)

"Without a next action, there remains a potentially infinite gap between current reality and what you need to do."

David Allen's Getting Things Done is the non-fiction book I've reread the most in my life. I reread it every couple of years and still pick up on new ideas that I missed before, or parts that resonate better now and I'm excited to implement. Before Google, I used to give this book to new employees as a welcome gift.

The book got an update in 2015, and I haven't read the new version yet, so I'm planning an extended GTD book club at work in Q2, spreading the book out over multiple sessions. (In fact, I did just that for the young adult version of the book with my 16 year old godson back home in Belgium) If you've run a GTD book club, drop me a line!

Find out more at Getting Things Done® - David Allen's GTD® Methodology

"Too many meetings end with a vague feeling among the players that something ought to happen, and the hope that it’s not their personal job to make it so. [...] ask “So what’s the next action on this?” at the end of each discussion point in your next staff meeting"

Taken from The Playlist - a curated perspective on the intersection of form and content (subscribe, discuss)

flattr this!

by Thomas at April 18, 2022 04:39 PM

April 16, 2022

Thomas Vander SticheleRebecca Solnit – Men Explain Things to Me

(Thomas Vander Stichele)

"Most women fight wars on two fronts, one for whatever the putative topic is and one simply for the right to speak, to have ideas, to be acknowledged to be in possession of facts and truths, to have value, to be a human being."

In honor of International Women's Day 2022 (this past March 8th), some quotes from the 2008 article that inspired the term "mansplaining": to comment on or explain something to a woman in a condescending, overconfident, and often inaccurate or oversimplified manner.

I've certainly been (and probably still am) guilty of this behavior, and this is a standing invitation to let me know when I'm doing it to you.

Read the original article with a new introduction at Men Explain Things to Me – Guernica

"None was more astonishing than the one from the Indianapolis man who wrote in to tell me that he had “never personally or professionally shortchanged a woman” and went on to berate me for not hanging out with “more regular guys or at least do a little homework first,” gave me some advice about how to run my life, and then commented on my “feelings of inferiority.” He thought that being patronized was an experience a woman chooses to, or could choose not to have–and so the fault was all mine. Life is short; I didn’t write back."

Taken from The Playlist - a curated perspective on the intersection of form and content (subscribe, discuss)

flattr this!

by Thomas at April 16, 2022 02:37 PM

April 14, 2022

Thomas Vander SticheleDraft emails from Google Docs

(Thomas Vander Stichele)

In the ever more vertical company that Google is becoming, it is even more important to collaborate on some of your communication - more people want to contribute to the message and get it right, and more thought needs to be given to the ever wider audience you're sending mails to.

A while back I copied over AppScript code from an internal Google project to send meeting notes to make a different tool which makes it easy to go from Google Docs draft to a mail in GMail and avoid embarrassing copy/paste errors. I'm happy to be able to retire that little side project in favor of a recently released built-in feature of Google Docs: Draft emails from Google Docs - Docs Editors Help

Taken from The Playlist - a curated perspective on the intersection of form and content (subscribe, discuss)

flattr this!

by Thomas at April 14, 2022 03:33 PM

April 07, 2022

Christian SchallerWhy is Kopper and Zink important? AKA the future of OpenGL

(Christian Schaller)

Since Kopper got merged today upstream I wanted to write a little about it as I think the value it brings can be unclear for the uninitiated.

Adam Jackson in our graphics team has been working for the last Months together with other community members like Mike Blumenkrantz implementing Kopper. For those unaware Zink is an OpenGL implementation running on top of Vulkan and Kopper is the layer that allows you to translate OpenGL and GLX window handling to Vulkan WSI handling. This means that you can get full OpenGL support even if your GPU only has a Vulkan driver available and it also means you can for instance run GNOME on top of this stack thanks to the addition of Kopper to Zink.

During the lifecycle of the soon to be released Fedora Workstation 36 we expect to allow you to turn on the doing OpenGL using Kopper and Zink as an experimental feature once we update Fedora 36 to Mesa 22.1.

So you might ask why would I care about this as an end user? Well initially you probably will not care much, but over time it is likely that GPU makers will eventually stop developing native OpenGL drivers and just focus on their Vulkan drivers. At that point Zink and Kopper provides you with a backwards compatibility solution for your OpenGL applications. And for Linux distributions it will also at some point help reduce the amount of code we need to ship and maintain significantly as we can just rely on Zink and Kopper everywhere which of course reduces the workload for maintainers.

This is not going to be an overnight transition though, Zink and Kopper will need some time to stabilize and further improve performance. At the moment performance is generally a bit slower than the native drivers, but we have seen some examples of games which actually got better performance with specific driver combinations, but over time we expect to see the negative performance delta shrink. The delta is unlikely to ever fully go away due to the cost of translating between the two APIs, but on the other side we are going to be in a situation in a few years where all current/new applications use Vulkan natively (or through Proton) and thus the stuff that relies on OpenGL will be older software, so combined with faster GPUs you should still get more than good enough performance. And at that point Zink will be a lifesaver for your old OpenGL based applications and games.

by uraeus at April 07, 2022 06:14 PM

March 31, 2022

Thomas Vander SticheleThe COVID Cocoon

(Thomas Vander Stichele)

"The global COVID-19 pandemic has had countless impacts on society. One interesting effect is that it has created an environment in which many people have been able to explore their gender identity and, in many cases, undergo a gender transition. As organizations return to in-person work, be it full-time or hybrid, there is a greater chance of “out” transgender, non-binary, or gender non-conforming employees in the workforce." (From the "5 Ally Actions Newsletter - Mar 25, 2022")

March 31 is the Transgender Day of Visibility. The COVID Cocoon is a nickname given for the phenomenon of people discovering their gender diversity during the pandemic environment.

The full report is an interesting read; one recommendation that we can all contribute to is on Culture and Communication: Proactively communicating that gender diversity is accepted, asking staff for their input, and being open and ready to listen helps create a culture where employees can feel safe, welcome, and valued.

Taken from The Playlist - a curated perspective on the intersection of form and content (subscribe, discuss)

flattr this!

by Thomas at March 31, 2022 11:46 PM

March 28, 2022

Thomas Vander SticheleBuilding a Second Brain

(Thomas Vander Stichele)

"Your Second Brain is for preserving raw information over time until it's ready to be used, because information is perishable. Your Second Brain is the brain that doesn't forget." - Tiago Forte

Personal Knowledge Management is going through a wave of innovation with new tools like Roam, Logseq, Obsidian, Notion, RemNote, and others gaining traction over Evernote, OneNote and the like. It's a great time to get curious or reacquaint yourself with the tools and processes that strengthen learning, processing, and expressing your knowledge work.

The expression "Second Brain" has been popularized by Tiago Forte, who's been running an online cohort-based class called Building a Second Brain I took the class last year and found it a powerful distillation of an approach to PKM and note-taking. If you want to learn more, they just wrapped up the Second Brain Summit and posted all videos online: Second Brain Summit 2022 - Full Session Recordings - YouTube

The next class cohort is open for enrollment until March 30th midnight ET, at Building a Second Brain: Live 5-Week Online Course, and runs from April 12th to May 10th, 2022.

"Taking notes is the closest thing we have to time travel." - Kendrick Lamar

Taken from The Playlist - a curated perspective on the intersection of form and content (subscribe, discuss)

flattr this!

by Thomas at March 28, 2022 08:44 PM

March 14, 2022

GStreamerGStreamer 1.20.1 stable bug fix release


The GStreamer team is pleased to announce the first bug fix release in the stable 1.20 release series of your favourite cross-platform multimedia framework!

This release only contains bugfixes and it should be safe to update from 1.20.0.

Highlighted bugfixes:

  • deinterlace: various bug fixes for yadif, greedy and scalerbob methods
  • gtk video sink: Fix rotation not being applied when paused
  • gst-play-1.0: Fix trick-mode handling in keyboard shortcut
  • jpegdec: fix RGB conversion handling
  • matroskademux: improved ProRes video handling
  • matroskamux: Handle multiview-mode/flags/pixel-aspect-ratio caps fields correctly when checking caps equality on input caps changes
  • videoaggregator fixes (negative rate handling, current position rounding)
  • soup http plugin: Lookup libsoup dylib files on Apple platforms; fix Cerbero static build on Android and iOS
  • Support build against libfreeaptx in openaptx plugin
  • Fix linking issues on Illumos distros
  • GstPlay: Fix new error + warning parsing API (was unusuable before)
  • mpegtsmux: VBR muxing fixes
  • nvdecoder: Various fixes for 4:4:4 and high-bitdepth decoding
  • Support build against libfreeaptx in openaptx plugin
  • webrtc: Various fixes to the webrtc-sendrecv python example
  • macOS: support a relocatable `GStreamer.framework` on macOS
  • macOS: fix applemedia plugin failing to load on ARM64 macOS
  • windows: ship wavpack library
  • gst-python: Fix build with Python 3.11
  • various bug fixes, memory leak fixes, and other stability and reliability improvements

See the GStreamer 1.20.1 release notes for more details.

Binaries for Android, iOS, Mac OS X and Windows will be available shortly.

Release tarballs can be downloaded directly here:

March 14, 2022 12:00 PM

March 09, 2022

Jean-François Fortin TamPlease adapt Mozilla’s code so that PDF readers on Linux can handle XFA forms!

Y’know, all those horrible government forms?

No, I mean the digital ones, meant to be opened specifically with Adobe Reader?

Well, in Q4 2021, Mozilla’s PDF.js landed support for XFA PDF forms, so Firefox is now able to deal with them, which is huge deal, as we have been increasingly encountering such documents over the years, and still will be for a long time, especially given how slow-moving governments can be when it comes to their digital practices.

It would be fantastic to see these code insights put to use in Poppler, the library that Evince, Okular and other applications use… so if someone feels like fixing one of the few biggest issues with reading/filling PDFs under Linux, please use this code (see also: all the XFA-related pull requests) as inspiration to contribute a fix to this and that issue in Poppler!

Of course, there are remaining issues related to forms in PDF.js, but it’s still better than nothing; and perhaps your efforts in replicating this functionality into Poppler can lead to interesting cross-project findings that can also benefit the PDF.js project?

by Jeff at March 09, 2022 10:55 AM

March 03, 2022

Jean-François Fortin TamGetting Things GNOME 0.6 released

Yes, ladies, gentlemen, and seemingly-dead plants, it’s happening: after over 10 months of incremental work from the community, we are now releasing version 0.6 of our favorite personal productivity app, Getting Things GNOME. This release comes with some new features, lots of code improvements, many bugfixes and UX refinements (I am told that the “Better procrastination button”, presented below, deserves a place in the Museum of Modern Art).

Save the children, and the parents… tasks.

GTG 0.6 includes fixes for a long-standing higgs-bugson crasher, that would happen under some unpredictable conditions (such as issue 595 and issue 724) and was therefore hard to reproduce for a long time… until I hit the point, in my chaotic 2021 year, where I had accumulated over 2500 tasks as I forgot to clean my closed tasks for a few months… when your data file is that big, the bug becomes much easier to trigger.

We also fixed this mandelbug that would make GTG show inconsistent results in the list of tasks, under some circumstances. Neui was able to deduce the cause for the problem by looking at the tracebacks, and provided a fix in liblarch. GTG 0.6 will therefore require an updated version of liblarch.

Those two deeply nested bugs are the reason why I’m officially codenaming this release… “Shin Kidō Senki GTG Wing: Endless Recursion”.

(Insert a Zimmer-style “bwaaah” brass sound effect here. An Auralnaut is fine too.)

“Where’s my cal, Dave?”

Hey, we have a new synchronization backend now! If you have a CalDAV server (for example, something with OwnCloud or YUNOHOST), you can use this to synchronize GTG across your multiple computers.

It’s been a long time in the works. I would like to thank Mildred for doing the initial research and coding, then François Schmidts for doing another attempt at coding this feature, and for being very patient with us until we could finally merge this, after a lot of other architectural work landed. I know it can sometimes be tough for new contributors to wait for their code to land in an established open-source project, and for that project to also release the code in a stable release.

(With apologies to Mildred, François, and Padmé.)

Check out the built-in user manual pages to learn how you can use the CalDAV sync feature. There’s an online copy of the user manual, too. So far nobody reported catastrophic failures, so this sync backend seems to be Enterprise Ready™, but if you do encounter issues related to the CalDAV backend, kindly report them (even better if you can help with fixes and refinements!)

Gamification plugin

Sometimes, a little extra playful motivation can help you go through your day. Part of the brainstorming for gamification and virtual assistant features, Mohieddine Drissi created an initial plugin to add some game-like elements to GTG:

Here too, apologies to Mohieddine and Padmé!

Please try out this new feature, and look at the ticket linked above. Do you see additional features that would be good to add? Should they be part of this plugin, or a separate plugin? Let us know.

Modernized tag editor

This is what it used to look like:

This is what it looks like now:

Better procrastination button

One of the most important buttons in my GTG workflow is the “Do it tomorrow” button, and its associated menubutton that lets you reschedule a task’s start date a couple of days into the future. I call that feature the “procrastination” button and this might sound a bit silly, but it really is just an essential way to manage a frequently-changing set of priorities, schedule and obligations, and a way to manage your energy levels.

This release improves this feature with some additional attention to detail:

  • Inspired by some initial work by Laurent Combe, First, “Neui” made some pretty impressive hackery to make this an adaptive button that would automatically change its label depending on the available window/screen width, which now makes GTG capable of fitting within a split-screen on smaller screen resolutions. He did this only with Python code within GTG, so in case you’re wondering, GTG is not dependent on libadwaita for this to function.
  • In issue #550, I detailed the various inconsistencies between this menubutton and the contextual (right-click) menus for deferring tasks. As we were nearing the 0.6 release, I had a “How Hard Can It Be, Really?™” moment and went through a late night coding session to scratch at least part of my design itch, as it had been annoying me for a year by now and I didn’t want to stare at it for another release cycle. So this pull request of mine solves at least one half of the problem, which is probably better than nothing. Anyone is welcome to finish the 2nd half; you might have to harmonize that code with Until then, here’s how it looks like now:

Errors will be noticed easily again

GTG used to have a fantastically avant-garde technological feature where it would automatically catch and display Python errors (tracebacks) in the graphical user interface. This feature got lost in what led up to the 0.4 release, but it is now making a comeback in GTG 0.6, thanks to Neui’s fine engineering work. It not only catches tracebacks, but also determines whether they are critical or if the application can possibly continue running. I did some UI & UX refinements on top of Neui’s version, and we now have this honest but still reasonably reassuring dialog:

If you click the expander, you get the traceback, along with some additional information, all neatly MarkDown-formatted so that it can be readily pasted alongside your bug report on modern bug trackers:

Of course, our software is perfect and you should never actually encounter such errors/uncaught exceptions, but… you never know. In the rare cases where this might happen, as a user, it’s better to be made aware if such a problem occurs—and the possibility of the application’s internal state being inconsistent—right when you trigger the issue, so that you can know what sequence of events led to a problem in the code, and report it in our issue tracker.

If you need to test this dialog (ex.: to test translations) but can’t find bugs in our flawless code, you can use GTG’s built-in “Developer Console” to trigger a traceback that will make that dialog appear (see this tip in our documentation).

Tough times, strong community

It’s been a hell of a year, but it’s still been less than a year since 0.5. Ideally we would be on a faster cycle, but we kept merging new and interesting things, and 2021 was pretty intense for many of us, so we slipped a bit.

Diego had to take time off to take care of his family and personal health, and I, certainly like many readers here, had a pretty busy year in my day-to-day work and beyond.

I deeply appreciate the GTG community’s patience in contributing, getting involved and sticking together to improve this project. Personally, I was not able to keep up very closely with all the activity going on; I received somewhere around 1900 emails related to GTG tickets and merge requests during the 0.6 cycle (from April 6th 2021 to this day), so it is clear that the community’s involvement is really strong here, and that’s awesome. If you’re not already part of this, consider joining the fun!

Let me take a minute to dish out some praise here for the fabulous and tireless work of our most frequent contributors. Thank you,

  • “Neui” for contributing a ton of patches, code reviews, advice, that helped the project’s technical architecture progress steadily throughout the year (also, thank you for investigating some of my craziest bugs and providing solutions for them!) ;
  • Diego, for plowing through architectural code refactoring, bugfixing, code reviews, during what I know was a difficult time;
  • Mildred and François, for making the CalDAV sync backend possible.
  • Mohieddine Drissi for creating the gamification plugin
  • Danielle Vansia, who not only updated and expanded the user manual so that you could know how the hell to use that CalDAV feature, but also kindly took Diego’s “changes since 0.5” braindump, expanded and polished it into the release notes you can find further below.
  • …and many other contributors who have made this release possible by providing bug fixes, code quality improvements, etc. They are listed in the about dialog’s credit section for this release, too 😉

Releasing because I can’t stand 0.5 anymore

You know, my gtg_data.xml file is pretty heavy:

No, I mean really heavy:

(Insert Hans Zimmer brass sounds)

As I write this, my data file contains over 2700 tasks (~1800 open, ~700 done, ~ 200 dismissed). The problem is, when you reach that kind of heaviness in your data file, in 0.5 you will encounter not only occasional crashes “when adding a parent/child task or when marking a recurrent task as done” (as mentioned at the beginning of this blog post), but also when trying to delete a bunch of tasks at once… which meant my “purge tasks” feature was not working anymore, which meant I kept piling on hundreds of “closed” tasks every month that I couldn’t easily remove from my tasks data file, which meant performance kept getting worse and crashes were getting more likely…

These are the total number of tasks in my XML file over time (including open, done and dismissed tasks). Each dip is when I tell GTG to purge closed tasks from the file. I know, those numbers keep going back up, higher and higher; I really need to find people to take care of some of my home and infrastructure bullshit, but that’s besides the point 😉

With those issues exacerbated by my “abnormally heavy” data file growing heavier every day, you can imagine that version 0.5 had become unbearable for me in my day-to-day use…

…therefore we have a perfect excuse to release version 0.6, which solves those issues! 😇
“Release when you can’t stand the previous release anymore!”

So here we are, GTG 0.6 comes right on time for income tax season! (and if it does help you make it through that period alive, maybe you can deduct some massive donations to Diego via LiberaPay or via GumRoad 😉 especially considering the metric crapton of refactoring work that will need to be accomplished for 0.7

Release notes

Thanks to Danielle, Diego and Neui for taking the time to research & detail the noteworthy changes to create the NEWS file, which you can read below.

New Features:

  • A new CalDAV backend is available, and the backends dialog is available again. CalDAV is a calendaring protocol that allows a client to access items from a server. GTG now provides support for this standard, and with this new sync service, you can manage all your tasks in one place.
  • The new “Gamify” plugin adds a game aspect to your GTG workflow, such as the ability to set task targets and task completion streaks.
  • The Tag Editor was completely redesigned.
  • Added support for undo/redo actions in the Task Editor.
  • Added the ability to collapse and expand all tasks in the main menu.
  • Added the F10 shortcut to open the main menu.
  • ESC now closes the calendar picker window.
  • Added the CTRL+B shortcut to set focus on the sidebar.
  • Added an option to set the due date to “today” in the context menu.
  • The “Mark as not done” and “Undismiss” actions were replaced by a unified “Reopen” action for closed tasks in the right-click context menu.
  • The “Start Tomorrow” button is now adaptive, so that the main window can be resized to smaller widths.
  • The task deferral menubutton (next to “Start Tomorrow”) now shows both weekday names and the offset number of days from today. It also allows easily deferring to 7 days instead of only 6 days, and the ordering of this menubutton matches better with other menus.

Backend, Code Quality, and Performance Improvements:

  • Reintroduced the global exception/traceback catcher, with a dialog showing up when an error occurs.
  • Made an improvement to avoid infinite loops when entering invalid dates in the Quick Add entry.
  • Made an update to prevent errors when no task is selected.
  • Removed some deprecation warnings.
  • Added StartupWMClass to make pinning on KDE work.
  • Used application ID as the window icon (so KDE shows the correct icon).
  • Made several changes in preparation for Gtk 4.0, as well as updated a number of deprecated GTK-related items.
  • Made a ton of PEP8 and style fixes.
  • Refactored the date class.
  • Updated the ability to render tag icons better on HiDPI.
  • Updated the anonymize script.
  • Added gtg://TASK-ID to the command-line help.
  • Added the -p parameter for profiling in
  • We migrated from “Nose” to “PyTest” for the test suite, as Nose is unmaintained.

Bug Fixes:

  • Fixed possible crash when trying to create parent task, and similar operations, when the “Open” tab has not been opened yet (maximum recursion depth error).
  • Made a change to save a task before creating a parent. This prevents an error that appeared when a task title would be reset after adding a parent.
  • Fixed an issue where tags were being duplicated.
  • Fixed an issue where tags and saved searches with the same name were being considered duplicates.
  • Fixed a bug where every editor window would come back if GTG wasn’t closed cleanly (i.e., shut down).
  • Made several fixes for scripts.
  • Fixed certain main menu entries not being selectable via the keyboard.
  • Fixed the cut-off when you expand the columns too much.
  • Fixed a regression where symbols in tags (e.g., dashes and dots) were not recognized by the Task Editor. Also, added support for a few more.
  • Fixed a bug where tags’ icon, parent, and color were not being removed in the XML file.
  • Fixed a bug that occured when GTG just starts up with no tasks selected, and the user tried to use the “Add Parent” hotkey.
  • Avoid blurry tag color rounded rectangles on non-HiDPI screens.

Documentation Updates:

  • Added documentation to the Contributor Docs for contributing to the User Manual (i.e., for writing help files).
  • Added information about using flamegraph for profiling GTG for performance documentation (in the Contributor Docs).
  • Updated the user manual for this release.

For more details on all of these new features, improvements, and fixes, see the 0.6 release’s milestone.

Time to "flatpak update", folks:

by Jeff at March 03, 2022 05:00 PM

March 01, 2022

Jean-François Fortin TamYear MMXXI in 8 minutes

Near the end of 2020, I put a lot of thought into reevaluating my business’ value proposition, strategy, and processes. It’s a good thing I did that back then, because 2021 was quite different from 2020; I had much less time to “deepthink”, and I spent a majority of 2021 on an intense work treadmill, which led to me micro-burning out three times in the process. Also, guilt about feeling like I’m not contributing to open-source enough.

In that year, I also noticed a lot of “shortened fuses” around me—a pervasive edginess throughout society—along with bully-type abuse in various places. It’s an interesting story to analyze from an experiential and psychological standpoint, but I’ll cover that in a separate blog post sometime, to keep this one simple (so it takes roughly 8 minutes to read).

For now, I’ll focus on the usual short summary of my work + personal + open-source discoveries and activities from 2021, without too much emphasis on the deeper chaos going on in that year.

Professional life year overview

  • My then accountants suddenly told me, in January of that year, that they would no longer be serving small businesses for income tax reports, and thus “We’re dropping you, good luck!” 🤯 I then spent weeks exhaustively searching and evaluating accounting firms to find a new partner, and eventually found a top-notch accounting duo to help me with income tax reports in the long term. I asked them hardball questions on their career objectives and whether/when they would drop me like a hot potato, and I told them I couldn’t go through another taxheartbreak. Now that I’ve found you, you better stay with me, nya?
  • Worked for a surprising number of clients throughout the year (including a couple NGOs, as you can see in this case study about an in-depth technical & financial feasibility study and that case study about a naming/branding consulting project). I’ll keep it at that for now, again to keep this blog post simple.
  • Throughout the year, I (re)built a lot of websites for myself, and realized again just how much time & effort this requires. Since I timed myself, I now have some quantitative insights to share with all of you wondering, “How Hard Can It Be?™”; see my “How long does it take to create a website? (and why your FLOSS project doesn’t need one)” article.
    • Publicly unveiled Regento, after having finally created its website, at the same time as I was doing some pretty intensive consulting work in April (y’know, when things happen “all at the same time”…), hence the 2nd micro-burnout of the year.
    • Reworked the idéemarque branding agency website contents entirely during the summer. Did not blog about it until now. The design isn’t especially fancy/flashy, but it’ll do, I guess.
    • Quietly created Atypica’s photo portfolio in the fall season. Did not blog about it until 2022.

Personal life year overview

  • Summer 2021, with the arrival of vaccines and nice outdoors weather in the North, felt exactly like this Tokyo-III scene:
Yes, I know, this is the scene where everything feels “normal” before shit hits the fan again. The parallels are uncanny.
  • You might remember that I tried a kratky hydroponic indoors garden in 2020, and had no luck with tomatoes. In the winter/spring of 2021 I thought, “Perhaps I need to try my luck again with a regular self-watering soil planter, and lots of artificial light”. Well, I did: since September 2021, I can confirm that even with that kind of setup and a 4′ vertical fluorescent light to supplement the winter’s natural light, the tomato plant does not flower (and thus does not fruit), and barely survives better than the previous kratky hydroponic experiment; possibly its slightly better mildew resistance this time around is due to the artificial light, but I am not sure.
  • Made my Brother multifunction printer’s scanner work again with Linux, by setting up a dedicated machine with lots of ugly hackery to make it work. Now it works, let’s not ever touch it again for the next five years.
  • German cockroaches got in (via a package I brought inside) during the summer. It creeped me the hell out. I went through some very extensive research on how to get rid of them effectively and without unintended side-effects. Long story short, I killed them all without using chemicals, but that messed up my quality of life for some months, as it definitely didn’t help my sleep quality. Spraying pesticides or using tape is harmful and pointless; the real trick is to use a very thinly sprayed fine layer of diatomaceous earth (so that it is invisible), lay a couple of boron-infused gel baits (Advion™ is impossible to find up here) in every corner of every baseboard near the nest, all while starving them from any food or water, then… waiting and having a lot of patience and trust in that method. Also, always having a vacuum cleaner on hand (I can confirm that they do not survive a cyclonic canister) and manoeuvering quickly to catch them late at night to reduce their numbers. It took two months (or 4 months if you take into account the last two months of “zero encounters”), and it was nerve-racking. I learned a lot in the process, and they are certainly never going to be an issue again.
  • I probably spent 30-60% of the year away from home because of the constant hammering most days. Did you know that a set of one 8-stories-high building and one 20-stories-high building spanning a whole street requires about 2000 piles for their foundations? It took them roughly 12 months to drive all those piles into the ground (it didn’t help that the GC was using only one or two pile drivers at a time).
Pro Tip™: this song really helps to cover it all up.

A most welcome visitor

My longtime friend Étienne suddenly came back to visit Canada again for the first time in two years. He was originally too shy to ask for my hospitality, so I insisted to have him as my honored guest and to host him for the whole 3 weeks of his stay in Montréal. Being able to spend so much time with him is a privilege I have not had since, I think, fifteen years (the previous time was probably 2006). The timing was perfect; after a whole year of stress and work that had left me eager to have some sort of change of pace in December, this was my mood in anticipation of spending time with him again:

We had fun fixing lots of stuff, and simply being care-free geeks on a vacation:

  • I helped him livestream a wedding, with some of my studio equipment and the wonder of OBS Studio. I also took a couple hundred photos of the event.
  • He brought me a bunch of VoIP deskphones for my office, originally taken from an office in Tokyo. I’m now ready to open up a call center or something.
  • He brought me a replacement Nintendo Gamecube controller, again from Japan. Now we can honestly play Super Smash Brothers Melee again!.. if only having multiple guests was still a thing nowadays.
  • He completely tore down, cleaned and reassembled my projector (that I had föked up a year prior by accidentally blowing some dust onto the projector’s DMD chip, and that I did not have the time nor courage to fix by myself until that point). I’d like to think I helped with this deep-cleaning process as an assistant, but frankly he did all the difficult work, as you can see:
Étienne starting disassembly Optical block (sensor and lens assembly) taken out Lens taken out Separating the DMD chip from its PCB
  • He contaminated me with the wonder that is the “future funk” music genre, particularly Moe Shop‘s music.
  • He helped me make my other Brother printer work over the network.
  • I had never had the time and energy to mess with my router in the past year after its initial setup, so he flashed a new version of OpenWRT and finally figured out how to make multi-frequencies multi-SSD networks work seamlessly.
  • More importantly, it gave me the opportunity to have lengthy discussions with him and see what projects he’s been working on, and see how he’s been doing mentally, physically, and in terms of life trajectory. Being oceans apart for years meant that it was more difficult to check on friends’ well-being, so I welcomed the opportunity to catch up.

Open-source findings

  • Did you know that the “Gnome” icon theme still exists, and is not the same as the “Adwaita” icon theme?
  • I proposed an epic wallpaper concept for Fedora, but it went nowhere, much to my surprise.
  • I found the sudden disappearance of the GNOME Swedish Conspiracy to be an unacceptable loss to our shared cultural heritage; therefore I filed this formal inquiry into the matter, issue number 1.
  • Successfully lobbied for Planet GNOME to properly support Unicode blog posts, including emojis. You’re welcome 😇
  • Filed a couple of Jitsi UX issues from my observations, during the pandemic, of computer-illiterate users’ difficulties with this open-source WebRTC videoconferencing app. I’m happy to see now that many of them have been fixed.
  • Was pleased to see XFA PDF forms now being supported in Firefox. Look forward to my blog post on March 9th to learn about the possible implications.
  • Discovered that you can actually export addressbooks to .CSV in Evolution, but that capability is not presented in the GUI and you really need to know it exists at all.
  • Want to contribute an easy UX refinement to Evolution’s mail composer GUI? How about modernizing the hyperlinking dialog using GtkPopover? Check out the other newcomers-friendly tasks too.
  • Heads up all Evolution die-hards who would like to escape Google Calendar but still can’t because of visual info density: I’ve now re-filed my old bug report on the matter: “Upcoming weeks” / “Next 3 weeks” future events view mode. Give it a 👍 or consider contributing a patch if you’re more competent than me (as you most certainly are).
  • Suggested my amazing, revolutionary™ timeout-based search architecture for GTG. The results, as seen in GTG 0.5 and newer (such as 0.6, planned for release in the coming days) is a dramatic improvement in performance; search takes 1-3 seconds instead of 17+ seconds in heavy data sets.
    • I made the same recommendation in Simple Tab Groups for Firefox and the results were dramatic, as enthusiastically tweeted. You’re welcome.
    • As tweeted: I made the same live search method recommendation for Nautilus, the GNOME files manager. See this ticket (and please contribute a patch to the project, if you can).
    • As tweeted: I also filed a ticket to make the same suggestion—use a timeout-based search-as-you-type approach—for GTK’s FileChooser widget. I’m just wildly guessing, but this might be a reasonably easy-enough bug for a newcomer to contribute a patch for, but at the same time, this is GtkFileChooser we’re talking about, you’re certainly bound for technical surprises (but a great learning opportunity).

Miscellaneous findings

  • Realized part of why I’ve accumulated such a huge backlog of subjects to blog about here over the years, with so few actually getting published: this heat matrix of mine shows that the technical but low-impact topics are endless! High technicality = high accuracy and documentation requirements, a tremendous investment of time (each of my blog posts typically takes multiple days of work); if there is no clear impact/reward, then there is little incentive when there are so many other imperatives in life.
  • Realized that 78% of the USA’s cash (of all time) appeared out of thin air within the month of May 2021, and I still don’t understand how this stock market bubble that has been going on since 2011 keeps going without popping, with all that’s been going on in 2020-2021. Markets sure can stay irrational longer than we can stay solvent or sane.
  • Invented a method to reinforce cheap leatherette keychains with zipties.
  • Found some rusted, abandoned cast iron cookware in my building’s recycling room, and embarked on an adventure to learn all about cast iron and how to properly season and maintain it. With my eight back-to-back grapeseed oil seasoning passes in the oven, I think I did a pretty good job at seasoning them. So I guess I’m part of the Cast Iron Cult now. Considering that properly seasoned cast iron is naturally non-stick, who needs Teflon?! Besides, you can never have too many mêlée weapons. Even the Government of Canada basically says that cast iron and stainless steel are probably the only things that you can really trust (from a health/safety perspective)…
  • Discovered that you can sanitize (and endlessly reuse) N95 and surgical face masks, by using an electric pressure cooker (such as an Instant Pot) as a dry heat autoclave.
  • For all you nerds whose glasses keep slipping off your nose: binder clips! (no, not really… turns out there are silicone ear retainers out there)

by Jeff at March 01, 2022 09:45 PM

February 27, 2022

Thomas Vander SticheleTime in Meetings

(Thomas Vander Stichele)

article #productivity

Meetings are both necessary and useful, but they fragment your week, your opportunity for flow, and you need non-meeting time for your output as a knowledge worker.

"Those of us on the maker's schedule are willing to compromise. We know we have to have some number of meetings. All we ask from those on the manager's schedule is that they understand the cost." - Paul Graham, Maker's Schedule, Manager's Schedule

flattr this!

by Thomas at February 27, 2022 10:25 AM

February 25, 2022

Thomas Vander Sticheleapenwarr@ – The Gift of It’s Your Problem Now

(Thomas Vander Stichele)

#article #log4j

"Sometimes the gift interprets JNDI strings in my log messages and executes random code from my LDAP server. This is the nature of gifts."

An interesting musing on the nature of gifts, big companies and startups, and free software, from apenwarr@

Taken from The Playlist - a curated perspective on the intersection of form and content (subscribe, discuss)

flattr this!

by Thomas at February 25, 2022 06:25 PM

February 23, 2022

Jean-François Fortin TamHow long does it take to create a website? (and why your FLOSS project doesn’t need one)

The 20192020 period was a long R&D cycle for me, with a whole herd of yaks to shave, however it did give me new tools and abilities, such as the capacity to rapidly develop modern-looking websites without hand-coding them nor spending hours fruitlessly searching for—and being disappointed by—”suitable” themes.

One might wonder why then, with those upgraded skills, I didn’t seize the opportunity to make a new website for GTG or other open-source projects that could benefit from fancier marketing.

The short answer is, even if my tooling and technique have improved, it’s still a metric crapton of work. It might seem easy (“Use Hugo!”, “Just slap a couple of pages together!”, etc.) but there’s much more to building a website than just the technical design and coding (or integration) aspects. This article provides you with an idea of the amount of time it takes to plan, write, design and build a “reasonably simple” website with a dozen pages or so.

As a case in point, the website of my Montreal branding agency has been out there for many years, but right up until 2021, it was all hand-coded—and therefore, not really maintainable nor scalable to a team. One of the things I did in 2021 was to completely revamp it, by:

  • Switching it to WordPress instead of my own static HTML + CSS + PHP glue system I had perfected since the mid-2000’s (if you find that blasphemous, have a look at why I chose WordPress over other solutions for my business websites).
  • Rethinking all the contents.
  • Designing a basic layout to hold it all together, because frankly (and somewhat ironically) we didn’t have time to be obsessing about the visuals here.

Overhauling (or creating) a website is never a simple affair when you want to do things right for your project or business. Planning, writing & designing two of my new websites in 2021 required an investment of well over 230 hours of work. Among those were roughly 112 hours of work (at least, those I remembered to track) spent on the idéemarque website specifically, broken down roughly as follows:

  • 22 hours preparing a strategic positioning & structure document
  • 20 hours writing the new website’s “core pages” text, in two languages
  • 20 hours integrating the text into the website and laying out the pages’ overall design
  • 40 hours writing and laying out the 4 initial case studies, in two languages
  • ?? hours setting up and integrating an email notifications (newsletter) system, for those who want to know when a new article comes out
  • 9 hours (so far) sketching and drawing team members, and researching possibilities (a story for another day)

112+ hours, for a 18-pages website, is actually pretty damned fast: business websites typically tend to take much more time than that. This was made possible by circumstances rarely found with client work: I knew exactly what I was doing (from a technical standpoint), where I was going (from a marketing standpoint), and what I wanted to put in there (from a copywriting standpoint). Your mileage will almost certainly vary, especially if working with a large corporate team or committee where you can’t just directly pour all the content straight from your mind.

Those numbers do not include the R&D (and infrastructure maintenance) I did in previous years to actually get to the point where I could efficiently build such websites.

And, y’know, once you have a website out there, you need to feed it with new content, and to announce it. I spent an unknown amount of hours (probably well over 20-40; forgot to track them) planning and working on draft email announcements that kept getting outdated as the months went by—because I kept having to deal with emergencies, and because I kept moving the goalposts of what constituted a “good enough” website to write home about (nothing is more dangerous than “oh, one more thing…”). Me, a perfectionist? Nooooo.

So yeah… this is why I’m no longer spending that kind of time and energy building websites for my open-source projects, especially as FLOSS projects have contents that need to change much more frequently than most small-to-medium business websites. In the case of GTG, while I hate GNOME’s MoinMoin wiki, it Does the Job™ and it’s Good Enough to stay as it is; it’s still easier to maintain than a website. So y’know what? Your open-source project doesn’t need a website, unless it’s also a business or charitable organisation.

by Jeff at February 23, 2022 03:56 PM

February 22, 2022

Thomas Vander SticheleIsabel Wilkerson – Caste: The Origins of Our Discontents

(Thomas Vander Stichele)

Isabel Wilkerson - Caste: The Origins of Our Discontents

#book #dei

"Like other old houses, [...] has an unseen skeleton, a caste system that is as central to its operation as are the studs and joists that we cannot see in the physical buildings we call home. Caste is the infrastructure of our divisions. It is the architecture of human hierarchy, the subconscious code of instructions for maintaining [...] a [...] social order."

Caste has taken the lead in my library as the most highlighted book, and is a deep exploration of Caste as the lens through which to see discrimination, drawing parallels between Europe, the United States, and India, providing a universal framing.

“Young people,” he said, “I would like to present to you a fellow untouchable from the United States of America.” King was floored. He had not expected that term to be applied to him. He was, in fact, put off by it at first.

Taken from The Playlist - a curated perspective on the intersection of form and content (subscribe, discuss)

flattr this!

by Thomas at February 22, 2022 05:35 PM

February 21, 2022

Thomas Vander Stichele9 Ways We Self Sabotage

(Thomas Vander Stichele)

9 Ways We Self Sabotage

#survey #productivity

"Saboteurs are the voices in your head that generate negative emotions in the way you handle life’s everyday challenges. They represent automated patterns in your mind for how to think, feel, and respond. They cause all of your stress, anxiety, self-doubt, frustration, restlessness, and unhappiness. They sabotage your performance, wellbeing, and relationships."

Positive Intelligence is a mental fitness framework and, among other concepts, taught me helpful practical ways to deal with stress, both professionally and personally.

Take the test or read more on How we self-sabotage

Taken from The Playlist - a curated perspective on the intersection of form and content (subscribe, discuss)

flattr this!

by Thomas at February 21, 2022 07:21 PM

February 20, 2022

Jean-François Fortin TamGTG 0.6 release candidate

Today we are publishing a “release candidate” version of Getting Things GNOME 0.6. You can either try it out directly from the git master version (by running; see the general instructions), or from the testing package available on Flathub’s “beta” repository, separately from the standard stable flathub/flatpak release you may already be running. To run it as a flatpak, simply run these two commands:

flatpak remote-add flathub-beta
flatpak install org.gnome.GTG

…and choose the flathub-beta as the repository source to install GTG. Note that for some technical reasons, it will still say it’s version 0.5 if you look in the About dialog, but it really is 0.6 behind the scenes.

This release candidate is supposed to be stable and regressions-free, and is intended to:

  • Give translators an opportunity to update their favorite language(s) before the final release. You have roughly a week where you can voice your interest and provide us with an updated translation, if desired. The translation template (.pot file) has already been updated in the git version.
  • Give the opportunity for users to feel confident in trying out the current git version (or flatpak package above) and to easily check that everything is OK (and if not, report bugs).

This is the last call! If you haven’t tested out the git version recently, now would be a great time to test the release candidate and ensure there are no last minute issues we might have overlooked. If no showstoppers/regressions are found, we expect to release GTG 0.6 around the end of the month (roughly in a week).

by Jeff at February 20, 2022 04:20 PM

February 19, 2022

Nirbheek ChauhanBuilding GStreamer on Windows the Correct Way

For the past 4 years, Tim and I have spent thousands of hours on better Windows support for GStreamer. Starting in May 2016 when I first wrote about this and then with the first draft of the work before it was revised, updated, and upstreamed.

Since then, we've worked tirelessly to improve Windows support in GStreamer  with patches to many projects such as the Meson build system, GStreamer's Cerbero meta-build system, and writing build files for several non-GStreamer projects such as x264, openh264, ffmpeg, zlib, bzip2, libffi, glib, fontconfig, freetype, fribidi, harfbuzz, cairo, pango, gtk, libsrtp, opus, and many more that I've forgotten.

More recently, Seungha has also been working on new GStreamer elements for Windows such as d3d11, mediafoundation, wasapi2, etc. Sometimes we're able to find someone to sponsor all this work, but most of the time it's on our own dime.

Most of this has been happening in the background; noticed only by people who follow GStreamer development. I think more people should know about the work that's been happening upstream, and the official and supported ways to build GStreamer on Windows. Searching for this on Google can be a very confusing experience with the top results being outdated links or just plain clickbait.

So here's an overview of your options when you want to use GStreamer on Windows:

Installing GStreamer on Windows

GStreamer has released MinGW binary installers for Windows since the early 1.0 days using the Cerbero meta-build system which was created by Andoni for the non-upstream "GStreamer SDK" project, which was based on GStreamer 0.10.
Today it supports building GStreamer with both MinGW and Visual Studio, and even supports outputting UWP packages. So you can actually go and download all of those from the download page:

This is the easiest way to get started with GStreamer on Windows.

Building GStreamer yourself for Deployment

If you need to build GStreamer with a custom configuration for deployment, the easiest option is to use Cerbero, which is a meta-build system. It will download all the dependencies for you (including most of the build-tools), build them with Autotools, CMake, or Meson (as appropriate), and output a neat little MSI installer.
The README contains all the information you need, including screenshots for how to set things up:

As of a few days ago, after months of work the native Cerbero Windows builds have also been integrated into our Continuous Integration pipeline that runs on every merge request, which further improves the quality of our Windows support. We already had native Windows CI using gst-build, but this increases our coverage.

Contributing to GStreamer on Windows

If you want to contribute to GStreamer from Windows, the best option is to clone the gstreamer monorepo (derived from gst-build which was created by Thibault), which is basically a meson 'wrapper' project that has all the gstreamer repositories aggregated as subprojects. Once again, the README file is pretty easy to follow and has screenshots for how to set things up:

This is also the method used by all GStreamer developers to hack on gstreamer on all platforms, so it should work pretty well out of the box, and it's tested on the CI. If it doesn't work, come poke us on #gstreamer on OFTC IRC (or the same channel via Matrix) or on the gstreamer mailing list.

It's All Upstream.

You don't need any special steps, and you don't need to read complicated blog posts to build GStreamer on Windows. Everything is upstream.

This post previously contained examples of such articles and posts that are spreading misinformation, but I have removed those paragraphs after discussion with the people who were responsible for them, and to keep this post simple. All I can hope is that it doesn't happen again.

by Nirbheek ( at February 19, 2022 01:37 AM

February 18, 2022

Thomas Vander SticheleYou are not my papa

(Thomas Vander Stichele)

Last night I rode our bike home from Brooklyn, with my daughter crying loudly "You are not my papa!" most of the way.

We were a few minutes late picking her up from her class, and she was the last one there, crying in the arms of the teacher, and yelling something loudly, too loud to understand.
I picked her up, hugged her, asked what's wrong and tried to calm her down, but she wasn't having it. I put her in the back of our bike, strapping her in, checking with my son what she could be saying. We finally started making out that she was saying "not my papa".

I tried to convince her that I am, in fact, her papa, but she just kept repeating the same thing. We started our ride back home, and at the first red light I was acutely aware of her still yelling the same thing while standing still in traffic next to other bikes. What would I do if I was stuck in traffic next to a vehicle with a crying child yelling "You are not my papa?", I wondered. I started asking her questions like, "what hair color does your papa have?" to get her to stop and think, and I would respond, "that's interesting, just like me". I'd ask a few questions like that until the lights turned green.

I was hoping this would work for all the stops on our 25 minute ride home, and I was hoping we'd not run into any police cars along the way, just in case. Of course, two minutes later, I was parallel with a string of five police cars, all with their lights flashing. I kept repeating the questions at every stop, until she fell asleep as she usually does on the bike.

She slept all the way through dinner, and the next morning at breakfast I asked her, "who's your papa?" And she beamed at me and yelled, "you are my papa!"

My best guess at what happened is that at pickup she saw a string of papas pick up their kids, but didn't see me, and started saying "you are not my papa" at every other papa, until I was the last one to show up. I'll never show up last again.

flattr this!

by Thomas at February 18, 2022 01:30 AM

February 16, 2022

Robert McQueenForward the Foundation

(Robert McQueen)

Earlier this week, Neil McGovern announced that he is due to be stepping down as the Executive Director as the GNOME Foundation later this year. As the President of the board and Neil’s effective manager together with the Executive Committee, I wanted to take a moment to reflect on his achievements in the past 5 years and explain a little about what the next steps would be.

Since joining in 2017, Neil has overseen a productive period of growth and maturity for the Foundation, increasing our influence both within the GNOME project and the wider Free and Open Source Software community. Here’s a few highlights of what he’s achieved together with the Foundation team and the community:

  • Improved public perception of GNOME as a desktop and GTK as a development platform, helping to align interests between key contributors and wider ecosystem stakeholders and establishing an ongoing collaboration with KDE around the Linux App Summit.
  • Worked with the board to improve the maturity of the board itself and allow it to work at a more strategic level, instigating staggered two-year terms for directors providing much-needed stability, and established the Executive and Finance committees to handle specific topics and the Governance committees to take a longer-term look at the board’s composition and capabilities.
  • Arranged 3 major grants to the Foundation totaling $2M and raised a further $250k through targeted fundraising initiatives.
  • Grown the Foundation team to its largest ever size, investing in staff development, and established ongoing direct contributions to GNOME, GTK and Flathub by Foundation staff and contractors.
  • Launched and incubated Flathub as an inclusive and sustainable ecosystem for Linux app developers to engage directly with their users, and delivered the Community Engagement Challenge to invest in the sustainability of our contributor base ­­– the Foundation’s largest and most substantial programs outside of GNOME itself since Outreachy.
  • Achieved a fantastic resolution for GNOME and the wider community, by negotiating a settlement which protects FOSS developers from patent enforcement by the Rothschild group of non-practicing entities.
  • Stood for a diverse and inclusive Foundation, implementing a code of conduct for GNOME events and online spaces, establishing our first code of conduct committee and updating the bylaws to be gender-neutral.
  • Established the GNOME Circle program together with the board, broadening the membership base of the foundation by welcoming app and library developers from the wider ecosystem.

Recognizing and appreciating the amazing progress that GNOME has made with Neil’s support, the search for a new Executive Director provides the opportunity for the Foundation board to set the agenda and next high-level goals we’d like to achieve together with our new Executive Director.

In terms of the desktop, applications, technology, design and development processes, whilst there are always improvements to be made, the board’s general feeling is that thanks to the work of our amazing community of contributors, GNOME is doing very well in terms of what we produce and publish. Recent desktop releases have looked great, highly polished and well-received, and the application ecosystem is growing and improving through new developers and applications bringing great energy at the moment. From here, our largest opportunity in terms of growing the community and our user base is being able to articulate the benefits of what we’ve produced to a wider public audience, and deliver impact which allows us to secure and grow new and sustainable sources of funding.

For individuals, we are able to offer an exceedingly high quality desktop experience and a broad range of powerful applications which are affordable to all, backed by a nonprofit which can be trusted to look after your data, digital security and your best interests as an individual. From the perspective of being a public charity in the US, we also have the opportunity to establish programs that draw upon our community, technology and products to deliver impact such as developing employable skills, incubating new Open Source contributors, learning to program and more.

For our next Executive Director, we will be looking for an individual with existing experience in that nonprofit landscape, ideally with prior experience establishing and raising funds for programs that deliver impact through technology, and appreciation for the values that bring people to Free, Open Source and other Open Culture organizations. Working closely with the existing members, contributors, volunteers and whole GNOME community, and managing our relationships with the Advisory Board and other key partners, we hope to find a candidate that can build public awareness and help people learn about, use and benefit from what GNOME has built over the past two decades.

Neil has agreed to stay in his position for a 6 month transition period, during which he will support the board in our search for a new Executive Director and support a smooth hand-over. Over the coming weeks we will publish the job description for the new ED, and establish a search committee who will be responsible for sourcing and interviewing candidates to make a recommendation to the board for Neil’s successor – a hard act to follow!

I’m confident the community will join me and the board in personally thanking Neil for his 5 years of dedicated service in support of GNOME and the Foundation. Should you have any queries regarding the process, or offers of assistance in the coming hiring process, please don’t hesitate to join the discussion or reach out directly to the board.

by ramcq at February 16, 2022 02:48 PM

February 10, 2022

Jean-François Fortin TamYear MMXX summarized in 7 minutes

For some reason, I didn’t get to see much people, and didn’t have much client work revenue throughout that year. I’m not sure why 🤔

TwentyTwenty was filled with unexpected events, discoveries, and opportunities to think about a lot of things. As nobody needs to read another editorial about the pandemic, I will attempt to summarize that year without discussing lockdowns, habit disruptions or international politics. Since this blog post is mostly chronological it does start with some dark stuff, but that’s just how it goes, it gets better (I think) and, as usual, concludes with a bunch of open-source related things.

Personal life summary

  • In January, one of my students/friends, Aida, died with her husband Arvin and 174 other passengers. She was 33 years old, and had just obtained her PhD a few weeks earlier. That hit me pretty hard. Two years after this incident, I still think of them regularly—you do not forget someone you worked with for half a decade.
  • Another one of my students/friends, Samer, died three months later, under nebulous circumstances, in his mid-twenties. As it happened right as the lockdowns were kicking in, I unfortunately did not get to pay my respects in person as I had done for James, Aida and Arvin. We were barely a quarter into the year and I was already fed up with this bad movie plot but, you know… shikata ga nai.
  • Not much happened during the couple of months that ensued (or not much that I remember, as I think we all collectively went through time dilation), other than working on resurrecting the Getting Things GNOME project (and doomscrolling).

But wait, keep on reading…

  • I found and bought the legendary rare-itemu ThinkPad X220T. A dream come true. There are many ThinkPads like it, but this one is mine.
  • I discovered that my then-16-years-old WordPress blog—an Elder of the Internet—predates unicode standardization on the web and was therefore a mix of latin1_swedish_ci, utf8, and utf8mb4 😱 I had to do database surgery to fix this before a major PHP update would break everything. It took me months to solve this; story for another day. But at least the fact that you’ve been reading this retrospective makes it all worth it 😃
  • I honed my bicycle maintenance skills (simple examples here and here) and taught myself a lot about bike restoration. The most dramatic case was an old folding bike that had been left to rust to death by some careless owner:
Rusted front wheel/fender/brakes Rusted handlebar accessories Rusted handlebar chrome Beat-up fender, chain, wheels, etc. Rusted wheel spokes, axles, etc.

…and that I fixed up real good:

Around the same time period in the summer of 2020, mai waifu, who had been stuck abroad for the past 12 months at that point, decided to end our relationship, as the prospect of coming back didn’t seem likely anymore in the context of the pandemic. Well, shi—’kata ga nai, desu yo~

With that turn of events, I went back to my personal projects backlog with a whole new perspective and set of priorities. With only myself to answer to and to take care of, I was essentially… limitless. No waifu? No laifu!

  • Bit by bit, I completed a lot of “living space” improvement projects that had been put on hold. Since I now had free reign to buy/install/organize whatever I damned please in my mancave, that’s exactly what I did:
    • A bunch of office chairs and studio equipment in the living room? An accounting desk in a closet? A mobile tower of shelves in the water closet? Two visible pans racks on the countertops? Not-pretty-but-practical entryway rugs? Mobile wire rack shelving for conveniently storing equipment in plain sight? A 40-years-old floral wool carpet from Thaïland in the ultramodern studio? Yes to all of that! Whoever visits me from here on accepts the corporate and utilitarian nature of my premises, and that’s that. 😤
    • I have set up my home cinema with a dedicated computer connected to the projector, installed dark blackout curtains on rails on three walls, used dark floor foam tiles, and placed the surround speakers all around the room. The subwoofer is in an unusual orientation, firing horizontally (from behind the seating positions) while held by a DIY wooden platform atop vibration absorbers, on a inexpensive Sonopan sound absorption panel cutout, to reduce structural sound transmission to neighbors. It is a derivative of this idea I originally had.
    • In the same room, I have perma-installed the heavy (and rare) upcycled Cobalt Flux™ Dance Dance Revolution pads on top of heavy anti-fatigue bartender rubber mats (to prevent damaging the floor or transmitting step sounds). The Linux media center computer has a fully-loaded Stepmania on it, thanks to the existence of this flatpak. Yet somehow, throughout 2020, I wasn’t very much into the mood for dancing.
  • I set out to prepare to resume my independent practice for the next year, and diversify a bit. Therefore I created the website in the summer-fall of 2020 as a trial-by-fire deployment (even though there was no business to be made on that front with all the lockdowns), learned a lot from that, and from that successful experience, started strategic planning for two other specialized business websites I would develop throughout 2021.
I now sleep on the floor next to pro-grade DDR pads. I guess I’m living the Japanese Dream? 🤔

Miscellaneous findings & thoughts

  • Discovered that traditional Japanese archers are super stealthy.
  • I also discovered, near the end of 2020, that the ex-waifu had previously viciously murdered my bamboo plant in 2019 😲 We’re still good friends, although I think she can no longer be considered a model millenial.
  • After many weeks (months?!) of research, found a durable headphone earpads solution for my Sony MDR-7506 studio monitoring headphones, and made a video about it.
  • Was very saddened by Behdad’s story of his very unfortunate encounter with Iran’s state police. You should read that article if you hadn’t seen it. Also covered on CBC news and on Global news. I was relieved to know that he had at least made it out alive. If you’re too new in the GNOME community to instantly know who Behdad is, this is a person to whom we owe a lot of Cairo, Pango, and various other fundamental GNOME technologies.
  • Pro tip™ for Firefox tab hoarders out there who have trouble identifying/reading their tab titles to close or move them: set a minimum tab width of 150 or 200 pixels (instead of the default 76) by setting the browser.tabs.tabMinWidth property (in about:config) to 150. Thank me later.
  • Throughout the year I had become collapse-aware again, as the pandemic laid bare humanity’s division and general ineptitude at solving even “practice rounds” of large-scale issues; does not bode well from a climate crisis perspective. And as much as I love meeting my tech family at GUADEC, I feel like Philip Withnall was definitely right (see also his GUADEC 2019 talk, “Environmentally Friendly GNOME”, part 1 and part 2 and this forum question). I unfortunately do not have reassuring answers when it comes to the climate emergency, other than thinking that local urban vertical hydroponic farms are an interesting approach to the unsustainability and failability of land-based agriculture as we currently know it, and that we at least reportedly solved the ozone layer problem 😌
  • Speaking of hydroponics, I tried the kratky method. I wish I had great success to report with my indoors “victory garden”, but while basilico thrives in kratky, I never managed to get my tomato plants to fruit with just natural light, and it is a supremely time-intensive research process. Also, my tomato plants always tend to get powdery mildew. “Perhaps I need to try my luck again next year, with a regular self-watering soil planter and lots of artificial light”, I thought.

Open-source contributions and interesting bug reports

  • With Diego & friends, we resurrected the Getting Things GNOME project and published the 0.4 release (sorry to be mentioning this for the zillionth time here, but it’s technically part of that year’s history). Went on to talk about it, from an Open-Source Community Management & Project Management perspective, at the beginning of Linux Unplugged’s 361st episode, then presented at GUADEC 2020 on a related topic. Development and new releases have been ongoing since then.
  • I’ve taken the time to experiment a bit on Evolution using the GTK Inspector, to figure out the combination of properties needed to make Evolution’s attachments bar IconView look good, and shared my findings in this bug report. Reportedly some of those suggested improvements are supposed to show up in Evolution 3.41.3 and newer. As I am stuck on Fedora 33, I haven’t tested this myself yet.
Experimenting with Evolution’s attachments bar iconview

There were probably hundreds of other little open source contributions I did throughout 2020, but I can’t remember them all. I don’t know about you, but somehow my memory of that year is a little bit hazy.

by Jeff at February 10, 2022 09:35 PM

February 08, 2022

Jean-François Fortin TamYear MMXIX summarized in 5 minutes

As part of my seven-years retrospective, here’s a 5-6 minutes readable summary of what I did in 2019.

Personal life summary

  • Q4 2018’s intense professional stress was replaced by emotional exhaustion in 2019’s Q1 and Q2. Caring for folks who have residual schizophrenia comorbid with depression and high-functioning autism, really is a lot of work that turns your life upside down, especially when a portion of your support network ghosts or gaslights you as they do not see any of the things you see.
  • Continued work with fellow researcher Dr Julien Meyer. It was a pleasure to collaborate with him in my day-to-day, and we probably kept each other sane during a pretty long winter. I was really happy for him when he landed a fulltime professor job at Nancy’s university of architecture some months later, although I was sad to see him leave Montréal.
  • I bought some tatami mats to sleep on the floor and I was pretty happy with them, but my waifu kept complaining that they “smell like a farm’s barn” and I had to get rid of them. Such a waste. Shikata ga nai desu yo~
  • Was very pleased to see Greta Thunberg gaining traction as she expressed into words what I had been feeling for the better part of my life.
  • For administrative reasons, mai waifu had to leave Canada and go back to France. I told people, “She left with the dog!” (technically, she did, here’s proof)
Pictured: a corginapping
  • With experience, I can now say I love dogs, but do not have the lifestyle to adequately care for them as an urban dweller. I also do not miss picking up poop three times a day at -20°C, or feeling genuinely sorry for their boredom while I relentlessly work in front of a computer. Having a dog—which typically is a very active being—when you have a busy sedentary lifestyle seems… somewhat cruel.
  • Coincidentally, all my consulting contracts ended in the summer that year, including “that technology manufacturing company” whose business management strategy had grown increasingly intolerable for me and my professional ethos as CMO. Considering the fact that I had also stepped down from my remaining facility management board duties some months prior, this meant I was, for the first time in a long time, not receiving 400-500 emails per week anymore, which was quite pleasant. It felt like I was waking up from a lucid dream.
  • Overall, with those multiple changes in responsibilities having occurred by Q3 2019, my life suddenly became much simpler again. Since I also needed a change of scenery while I was in limbo for mai waifu’s return and my upcoming apartment move, I took the opportunity to spend most of 2019 doing R&D to fix or improve my processes and positioning. Namely, I:
    • overhauled my personal website again (the last round was in 2017) to increasingly focus it on my consulting services rather than pretty drawings and photos (which you can still find if you look hard enough);
    • recreated my personal YouTube channel (but I then some months later, as the pandemic struck, I ran out of time and energy to post new stuff. One day I’ll get back to it.);
    • spent most of 2019 fixing my web infrastructure on fire (including this blog, and many other sites, whether for bugfixes or security patching) and my personal tools, some of which can be read about in the first and second part of the “upgrade treadmill trilogy”: about servers, and about browsers and desktop tools.
    • I also fixed up my VoIP systems (personal and business phone infrastructure)
  • Sold a prime investment opportunity, via email, to two people who were living on a boat in the Caribbean. I am not making this up, and I swear it was 100% legit. It had nothing to do with cocaïne or a sentient La-Z-Boy. Sometimes I think I would have a much easier time being a salesman or broker than an open-source marketeer 😏
  • Joined the Instant Pot™ sect. Seriously, semi-automated electric multi-function pressure cooking is a revolution in efficiency for busy young professionals.
  • After many days of research and analysis, ordered prescription glasses online for the first time (through EyeBuyDirect). For those who have very strong short-sightedness and astigmatism, paying 100$ instead of 300-700$ for glasses, and being able to “try them on” virtually with a photo (which allows a standardized, systematic comparison, and being able to actually see yourself—because you’re short-sighted, of course you can’t see yourself when trying out glass frames in stores), is a game-changer.
  • Spent days upon days of research and thinking about acoustic treatment for my video production studio room. I thus have a lot of information on the matter, but never ended up putting it into practice, as 2020-2021 has been too much of a mess and I had to shelve that project.
  • Moved to a different appartment. There often are a thousand papercuts involved with settling in and fixing stuff in a new home, and in this case it took months. The interior design process for the new location could warrant its own story, but I don’t know if anyone would actually care to read (or hear) about that.
Pictured: packing stuff into boxes for moving out of the old apartment

Bug reports and open-source stuff

  • Discovered that thumbnails generation in Nautilus (GNOME “Files”) is extremely slow compared to other file and image managers, and reported the performance issue with my initial observations. There have been some community patches proposed there to alleviate the problem by making use of multiple CPU threads instead of a single one, but they have not yet been reviewed as of early 2022. I hope they will be considered eventually, along with further possible performance enhancements.
  • Discovered that there is a way, with some hidden dconf gsettings, to make Tracker not destroy your computer’s performance, by throttling its indexing performance to the minimum (org.freedesktop.Tracker3.Miner.Files.throttle = 20) and by tweaking another setting to delay its launch on login (org.freedesktop.Tracker3.Miner.Files.initial-sleep = 45).
    It posit that these settings should be the default behavior. There never is a good time for a background search database indexer to be hammering my desktop’s performance. Needing to instantly be able to search, right upon login, through a gigantic filesystem that was somehow never indexed before is not a thing.
  • Discovered that you can tell Evolution, the email client, to only show email notifications for certain accounts. Go set your preferences in the Plugin Manager’s “Mail Notification” built-in plugin.
  • Thoroughly appreciated being able to finally migrate from Firefox 57 to a recent (post-quantum) version of Firefox, as Drive4ik’s wonderful “Simple Tab Groups” extension proved to be bulletproof and provided an upgrade path from Quicksaver’s “Tab Groups” extension. Again, STG is an absolute must-have extension; if you’re a chaos warrior, use it; you’ll thank me later.
  • Pondered what to do about the fact that my password manager, Revelation, was being removed from Fedora. I’ll spare you the details, but after much research and thinking, I ended up converting all my passwords to… an encrypted spreadsheet. And that is my password management system now. At least I know it will still work 20 years from now.
  • Pondered what I would do considering that GTG, my favorite productivity tool I was fully dependent on, was getting deprecated from Fedora’s packages. The rest, if you’ve been reading my blog is history. Otherwise, check out this epic tale about the upgrade treadmill of open-source desktop applications.
  • Proposed a stupidly simple yet functional presenter notes user interface mockup for LibreOffice Impress in my decade old bug report. The mockup is also attached to the bug report. I’m not offering a Ferrari this time, but someone else did mention they would be happy to pay a thousand pounds to whoever implements this. Just sayin’.
  • Went to the GStreamer conference for the first time in six years, and made this short documentary video. I would like to sincerely thank the GStreamer Foundation for supporting my travel to attend the event, which allowed me to produce that video pro-bono.

Miscellaneous findings and lifehacks

  • Did you know that you can set the amount of floors or height of objects (like buildings, trees, etc.) in OpenStreetMap? That’s what I did, and if you use a 3D representation of OpenStreetMap, like the F4 map, you can see the difference, complete with the sun’s shadow projections depending on the time of the day.
    • Additional tip: as Alexandre Franke kindly points out, you can also use the free & open-source StreetComplete Android app to make edits on the go while walking around, and object heights is one of the questions the app might ask you to fill in.
  • Realized that Squall actually died at the end of Disc 1 in Final Fantasy VII, and the three subsequent discs were just his dying dream. Square Enix will never admit this, but this is the only plausible storyline I will now consider makes sense.

As 2019 ended I thought, “Alright, let’s finish tying loose ends, do some forecasting, and prepare for great business in 2020!”… Aaaah, such gleeful optimism! 🤭

by Jeff at February 08, 2022 01:18 PM

February 06, 2022

Jean-François Fortin TamYear MMXVIII summarized in 4 minutes

  • Was super excited to see a GNOME hackfest focused solely on investigating performance issues in GNOME Shell, and the great work that happened from 2019 to 2021 on that front. It made a huge difference.
  • Was thrilled that Mozilla finally got their sh!t together when it comes to performance in Firefox, with the initial release of Firefox Quantum in late 2017. This was one of the first times since 2010 where I had a somewhat solid argument to convince Chrome users to consider Firefox again. Personally however, I was stuck on pre-quantum Firefox up until 2019 due to my reliance on Quicksaver’s “Tab Groups” extension (the successor to the Panorama feature), which eventually got succeeded by Drive4ik’s “Simple Tab Groups” extension, which is an absolute must-have; if you’re a chaos warrior, use it—you’ll thank me later.
  • Participated in various Montréal urban design public consultation events, such as this one.
  • Went to FOSDEM for the first time. It was cold and wet, and I did not see any talks, but I did see Adrien Plazas and made him wear a horribly obnoxious blue shirt. In his presence, I discovered the marvel that are lambic beers, pretty much the only beer I ever liked in my life. How the rest of the world accepts drinking any other type of alcoholic beverage is beyond me. Sorry, Red Hatters, but the Starobrno doesn’t come anywhere close.
Pictured: meeting the elePHPant at FOSDEM. Allegedly not Adrien Plazas inside the costume.
  • Was given a full-length wool cloak, which is perfect for winter, especially when standing watch on windy days. Best waifu gift ever. I later had it modded, adding a faux-fur rim around the hood, additional hook loops, buttons, arm slits, etc. My childhood friends were deeply exasperated by my unconventional outerwear choices. I maintain that cloaks are eminently practical and superior to coats in many respects, and that I’m just too fashion-forward for my friends’ tastes.
  • Bought “swiftwater” Crocs shoes, again much to the exasperation of my close friends. Finally something that doesn’t rip apart in the span of two years (super comfortable and water-proof are also key advantages). They are even great for DDR!
  • Roadtripped the land of ice and fire, in the backseat of a minivan with a dozen friends. Can confirm: if you don’t like the weather in Iceland, wait five minutes. Otherwise, when devoid of humans, Iceland is a nice place. I guess I am the last generation to have experienced icebergs and WOW Air.
  • Visited various cities in Spain in the middle of summer. Re-learned Spanish in a week discussing with taxi drivers during GUADEC. Eastern and Southern Spain certainly has pleasant weather.
  • Sat in a bistro alley of Almeria with Tobias Bernard, Jordan Petridis and (I believe?) Jakub Steiner, as Tobias explained, with much passionate conviction, his plans to convince Linux distributions to ship only Adwaita (with a recoloring API) and stop theming GNOME apps. I definitely saw the appeal as an application developer myself, but as an (un)official member of the GNOME “Old Farts club” (I never got stickers or a pipe) who had witnessed the Desktop Wars of the mid-2000’s, and as someone who was enjoying the then undergoing reconciliation after six years of sometimes tense relationships with downstream vendors, I listened with some mild amusement and wished him good luck on achieving that diplomatically (fast-forward to 2021, it turns out that the most high-profile shitstorm came, to my surprise, from a pretty different downstream partner).
Crowd at GUADEC 2018
  • Discovered the fantastic tool that is SweetHome3D, and modelled a home in a day, with no prior 3D CAD/BIM software experience.
  • Discovered CHANS’ battery rebuild service for laptops, ebikes, power tools, etc.
  • Met and welcomed Dr Julien Meyer (seen below working in style on my terrace during the warm season) as a guest in my home for a month or two, until he would find an apartment to rent near the office. Wonderful gentleman with amazing all-around culture and artisanal skillset (complementing his architecture, engineering & construction research knowledge), that I am happy to count as a good friend to this day.
  • The waifu moved in with me for Q4 2018, along with an extremely lazy corgi dog. As she had been deeply abused by her work environment throughout 2018 to the point of utter burnout, she ended up taking an extended vacation in my home where I nursed her back to health from Q4 2018 to Q2 2019.
Behold, Mac Owain the corgi, quite possibly the laziest dog you could find in these lands. So lazy, in fact, that I had to drag it around like a floor mop to make it go outside, as you can see in this video.
  • My colleague/friend James ended his life at 39.
    I cried for the first time in probably twenty five years, wrote this farewell, and then traveled to his funeral where I found some closure.
    Incidentally, while I was there, I also saw some of the heartland and its social fabric. With my nascent awareness of “back row America“, the opioid epidemic and symptomatic despair deaths of the “forgotten people” (see also: the unnecessariat), it is then that I understood, I think, what led to the rise of Trumpism some years prior. Division in the USA is not necessarily about red vs blue states, nor just urban vs rural. It is, among other things, decades of collapsing socio-economic conditions and a general feeling of betrayal and being ignored by the establishment, all crystallized into an ideology of mistrust; thus why you can’t really recover that demographic once it has organized and radicalized.
François discussing with James, when we last met him at a get-together in San Francisco.
  • I completed my third yearly term on the two real estate boards of directors, and sought a replacement to fill my seat, as I was scheduled to move to a different location a few months later, and also because my life had gotten pretty darned complicated and stressful at this point. I might get involved there again someday, but in the meantime, the toughest part was done and the facilities were in good hands, so “mission accomplished”.
  • Around the same period, a certain technology manufacturing company started asking me to meet increasingly unreasonable objectives, such as near-single-handedly doubling/tripling sales every month (I believe anyone who worked in sales & marketing will laugh heartily at this), while also asking me to turn a blind eye to supply chain issues & product design considerations, which is just not what a true CMO does.

by Jeff at February 06, 2022 11:40 AM

February 05, 2022

Jean-François Fortin TamCHANS battery rebuild: giving traditional laptops a new life with refactored batteries cells

Back in 2018, when I acquired my legendary ThinkPad X220, I discovered that there is a lady in Ontario, Ms. Chulkova, who does professional battery rebuilding as a side-gig: if you’re in Canada (or the USA, to an extent) you can get your laptop (and other power tools) battery cells replaced by new high-quality cells. This is interesting if you have an electric bike or if, like me, you are a luddite who believes that the last great laptop keyboards were produced in 2011 (before the ThinkPad X230/T430/etc.) and that ultrabooks—with their proprietary slim LiPo batteries and general planned obsolescence—are an ecological disaster.

Ms Chulkova’s business is called CHANS. She’s not paying me to write this (and she never asked me for a review or anything of the sort), I just thought her business was worth mentioning, as I’m not sure it’s really a commonly encountered kind of business here.

At 45 CAD (+ shipping cost both ways, 2×15$ for a 1kg package in my case), this battery rebuild service is:

  • much better quality than no-name cheap chinese replacement batteries;
  • much less expensive than OEM batteries (which have always been at least 3 to 4 times that price, and might have been sitting on shelves for months at this point), which are not even really sold officially anymore, as far as I can tell any batteries you buy will be third-party aftermarket batteries;
  • much easier and more time-efficient than sourcing parts and rebuilding a battery myself, especially since she’s equipped to do spot welding, has specialized testing equipment, and uses special debugging software to reset the microcontrollers and ensure the batteries work.

I wish there was such a service locally in the Montréal metropolitan area (or even in Québec City) where I could drop off and pick up batteries to be reconditioned to save on shipping, but I didn’t find any (let me know if you find one someday).

When CHANS rebuilt my battery, Ms Chulkova mentioned she would use Samsung cells—second in quality only to Panasonic and Rhosgobel rabbits, I would assume—and indeed, the 9 cells I can see, as I opened up my ThinkPad X220’s battery, are Samsung-branded:

They worked great during the first year at least; I’m unsure what their behavior could have been like in years 2 and 3, because I stopped using the laptop 8 months after having the cells changed (as I picked up an even more exquisite ThinkPad X220T).

I started using the X220 again 2 years later, in the fall of 2021. After a few weeks, the battery died and suddenly wouldn’t hold a charge anymore, which is not entirely surprising; I wonder if it is primarily due to ageing (the cells being at least 3 years old at that point) or if sitting on a shelf (unplugged from the computer, at 50% charge) for a year killed them, or perhaps the microcontroller is confused. Or is there a way to easily deplete-recharge them or reset the controller to resurrect them? 🤔

My overall impression is that CHANS Battery Rebuild is good and honest business worth supporting, so if you are in need of getting like-new battery life out of old electronics that use battery cells, consider doing business with them (and let me know how it works for you in the long run). I will probably consider their services again when/if regular travel becomes a thing for me again.

by Jeff at February 05, 2022 11:35 PM