Improving the development experience for GNOME Settings

After Bastien and Rui announced that they were stepping down from maintainership of GNOME Settings, I went ahead and volunteered to take care of it. This was not a random act, though;  for quite some time, I’ve been adding and changing code all around. I was pretty involved in moving to the new layout, and with the help of other contributors, implemented the redesigns of various panels. Clearly, I have a technical debt to the app.

Adding to that, assuming maintainership over it also aligns well with the goals of my employer, Endless, and gives a nice upstream/downstream overlap. With that, I can spend a bigger chunk of my work time on upstream tasks. Moreover, it allows us to have a stronger relationship with the GNOME community — after all, it allows me to bridge the insights and knowledge we gain from our users to a wider community.

Turns out, GNOME Settings is a pretty popular app amongst our users. It is one of the top apps that our users run. Developing and improving it became an important part of our fixed set of tasks. Specially now that we’re on the verge of a big release and one exciting new feature (amongst many!) was added into Settings. I’ll write more about it soon, hold your horses! 🙂

Without further ado, let’s start by checking some facts about Settings.

Knowing Settings

  • It has 371 unique dependencies (give or take, depending on the distro);
  • As of today, there are more than 17,500 commits and 500 tags;
  • It has roughly 440,000 lines of code, effectively making it part of the huge apps of GNOME, together with Evolution, GNOME Builder and Mutter.
  • It has 24 panels, the latest one being Thunderbolt;
  • First commit dates back to February 10th 1998, 21:22:12

As you can see, this is really no regular GNOME app. It has an old code base, half a million lines of code, dozens of thousands of commits and went through a lot of contributors. During all this time, it has being serving as the central hub of hardware and modules setting management. This gives us the dimension of this app.

But life is not a bed of roses.

Problems

Of course, during this time, GNOME Settings aged, was rewritten at least three times, and more recently was ported to another build system, Meson. Maintaining an app of this size, with such a colossal amount of knowledge involved, is not easy.

As I learn and find my way around the code base, a few problems were found:

  • You need to have the development packages of everything to build it. This is obvious, but I don’t really enjoy messing up with my host system.
  • It is not trivial to debug Settings. There was only a rudimentary logging system around.
  • There are at least 4 different code styles being used, and none documented.
  • Tests were scattered all around the code base.

With that, the reader hopefully  has enough context to follow the rest of this article: the recent changes that make the development experience of GNOME Settings smoother and more streamlined.

Flatpak, Flakpat, Flaptak, Flatkap, Flapkat!

Flatpak is an application distribution module, and has high adoption from the GNOME community. Turns out, Flatpak also became an excellent development tool, much beyond my initial expectations. It allows me, as a developer, to have a finer control over the build and execution environment, and keeps my system clean and organized. It allows me to install multiple versions of a given app, and they’ll share every common file they have. It’s awesome.

Flatpak is also tightly integrated into GNOME Builder, and developing apps on Builder with Flatpak is a super smooth experience these days. Thanks to Christian Hergert, we have a prime quality IDE!

This led to the creation of a Flatpak manifest for GNOME Settings. Of course, GNOME Settings is not meant to run as a Flatpak by end users. The Flatpak integration is strictly for development purposes.

You'll be warned when running Settings with Flatpak.
You’ll be warned when running Settings with Flatpak.

Spotlights to the blueish “I am a development version” header bar:

Blue headerbars
Fancy header bar!

These details might seem small, but they transform the development experience from a burden to a breeze. One can literally clone GNOME Settings from GNOME Builder and just press the Run button – everything will happen automatically. Besides that, Flatpak integration means I can develop GNOME Settings in a locked host system, such as Endless OS or Fedora Atomic, without having to unlock it and install development packages.

This work was partially done in my work time. Thanks Endless for letting me improve my own workflow 😛

Faster CI

GNOME Settings gained rudimentary CI support just before the 3.28 release. It allows us to have fancy green icons on commits, like these:

CI in action
We’re in a good state, everything is building!

CI is important to make sure everything is always building and working fine. Merge requests are always built before being merged, and having a more automated contribution workflow benefits everyone.

But it was inefficient and bloated.

Thanks to the independent contributor Claudio André, the CI was completely revamped. The build process was shrinked, the build environment was standardized so we can reliably reproduce build failures, and the fat was trimmed. In fact, CI times were cut down from 17 minutes to 3 minutes in average.

Thanks Claudio for your contributions!

Tests, More and Better

Another important aspect of improving the development experience is adding more tests, that validate a larger portion of the code base.

Thanks to Red Hat’s Benjamin Berg, the tests in GNOME Settings were reorganized and improved. As a courtesy, more network tests were also added. These tests are integrated into the CI, and every contribution is tested in a job:

CI in Gitlab
The tests run on every commit, and every merge request.

For obvious reasons, tests are absolutely important to avoid regressions. Unfortunately, though, the tests available in GNOME Settings don’t cover even a tiny fraction of the code base. Writting tests is a great way to start contributing to GNOME Settings!

Thanks Benjamin for reorganizing the tests!

Documentation

In addition to all this mentioned work, I personally have been working on improving the developer documentation available in GNOME Settings. As first steps in that direction, the current code style was documented and contribution guidelines were added.

The goal here is that people unfamiliar with the code base can find answers about code style by their own, reducing the communication overload and making the whole contribution process more efficient. It is also important to clearly document what is the expected behavior of contributors.

Improving the documentation is another wonderful and easy way to contribute.

But That’s not all

Even though these advancements mark a real improvement over the current state, there is a long way ahead. Ideally, we want to automate everything that can be automated, and test everything that should be tested. Settings needs and deserves to have some fresh air and code!

A unmerged feature that Claudio worked on is generating development Flatpak bundles. This is useful to lower the testing barrier, since one wouldn’t need to build Settings AND all the dependencies whatsoever. Just download, double-click the file, install and run. Dead easy.

If you have ideas on how the DX can be improved, feel free to share them! I’d love to hear your comments, suggestions, and ideas.

Acknowledgements

I’d like to thank my employer, Endless, for letting me use part of my work time to develop what I developed. I’d also like to thank Red Hat’s Benjamin Berg for reworking the test suite; independent contributor Claudio André, for making the CI smooth and fast; and specially Bastien Nocera, for helping and advising and reviewing code even after stepping down from the maintainer position.

Advertisements

(PSA) GLib can now canonicalize file paths

Quick announcement: if you have a relative file path, and want to resolve it against another (absolute) path, GLib can do that now.

An example in C:

g_autofree gchar *path = NULL;
g_autofree gchar *another_path = NULL;

path = g_canonicalize_filename ("../../usr/bin", "/etc/foo");
another_path = g_canonicalize_filename ("../../usr/bin", NULL);

g_print ("%s \n", path); /* Result: "/usr/bin" */
g_print ("%s \n", another_path); /* Passing NULL uses the current working dir */

No I/O is involved. It handles double and triple slashes nicely too.

This is bug 111848. The bug was fixed exactly 15 years and 1 day after initially reported.

We wish you farewell, bug 111848.

(Thanks Philip Withnall for reviewing, and Endless for sponsoring this work. This bug was fixed entirely in my work time.)

The Infamous GNOME Shell Memory Leak

Memory graph

Greetings GNOMErs,

at this point, I think it’s safe to assume that many of you already heard of a memory leak that was plaguing GNOME Shell. Well, as of yesterday, the two GitLab’s MRs that help fixing that issue were merged, and will be available in the next GNOME version. The fixes are being considered for backporting to GNOME 3.28 – after making sure they work as expected and don’t break your computer.

First, I’d like to thank the GJS maintainer, Philip C., for all the hand-holding, the reviews, and the incredibly insightful discussions we had. Secondly, to my employer, Endless, for the support they gave me to fix this issue. And last but not least, to the Ubuntu folks, which made a public call for testing with the changes – this will give us confidence that the fix is working, and that backporting it will be a relatively safe and smooth process.

banner-down
As always, great new features and fixes are a courtesy of Endless

I’m writing this blog post with three goals in mind:

  1. Explain in greater details what is the issue (or at least, what we think it is), the journey to find it, and how it was fixed.
  2. Give more exposure to important extra work from other contributors that absolutely deserve more credits.
  3. Expose a social issue that showed up during this time, and open a discussion about it.

Memory Leak

To me, it all started when I saw GitLab’s ticket #64 passing by in the IRC channels. It was challenging enough, I was curious to dig into GNOME Shell/Mutter/GJS internals, perfect match. Of course, when you’re not familiar with a given codebase, the first step to fixing a bug is being able to reproduce it, so I started to play around with GNOME Shell to see if I could find a reliable way to reproduce it.

Well, I found a way and wrote a very simple observation: running animations (showing and hiding the Overview, switching applications using Alt+Tab, etc) was reliably increasing memory usage. Then a few people came in, and dropped bits of useful information here and there. But at this point, it was still pointing to a wide range of directions, and definitely there was not actionable task there. This is when OMG! Ubuntu first wrote about it.

Carlos Garnacho then came in and wrote a pretty relevant comment with important information. It was specially insightful because he put numbers on the guts of GNOME Shell. His comment was the first real solid step to uncover what was going on.

A week passed, and I experimented different toys tools in order to have a better understanding of memory management inside GNOME Shell. This is the kind of tedious work that nobody talks about, but I learned tons of new stuff, so in the end it was worth the hassle. I even wrote about my crazy experiments, and the results of this long week are documented in a long comment in GNOME/gnome-shell#64. I kept experimenting until I reached heapgraph, an interesting tool that allowed generating the following picture:

Memory graph
Notice the sudden drops of memory at x=42 and x=71

Well, as stated in the comment, GJS’ garbage collect was indeed collecting memory when triggered. Problem is, it wasn’t being triggered at all. That was the leading clue to one of the problems that was going on. One idea came to my mind, then, and I decided to investigate it further.

A Simple Example

Consider that we have a few objects in memory, and they have parent/child relationships:

Example 1
The root object is “1”

Lets suppose that we decided that we don’t need the root object anymore, so we drop a reference to it, and it is marked for garbage collection.

Example 2
The root object is now marked for garbage collection

If we destroy the root object, we would need to destroy the other objects related to it, and go destroying everyone that depended, directly or indirectly, on the root object. Traditionally, JavaScript objects track who they own, so the garbage collector can clean up every other dependent object. Here’s the problem: C objects don’t track who owns them; instead, they only track how many owners they have. This is the traditional reference counting mechanism, and it works fine in C land because C is not garbage collected. To the garbage collector, however, the C objects would look like this:

Example 3
The garbage collector has no means to know the relationships between C objects.

The garbage collector, then, will go there and destroy the root one. This object will be finalized, and the directly dependent objects will be marked for garbage collection.

Example 4
Only the directly dependent objects are marked for the next garbage collection.

But… when will the next GC happen? Who knows! Can be now, can be in 10 minutes, or tomorrow morning! And that was the biggest offender to the memory leak – objects were piling up to be garbage collected, and these objects had child objects that would only be collected after, and so it goes. In other words, this is not really a memory leak – the memory is not being lost. I’d label it as a “misbehavior” instead.

The Solution

While people might think this was somehow solved, the patches that were merged does not fix that in the way it should be fixed. The “solution” is basically throwing a grenade to kill ants. We now queue a garbage collection every time an object is marked for destruction. So every single time an object becomes red, as in the example, we queue a GC. This is, of course, a very aggressive solution.

But it is not all bad. Some early tests shows that this has a small impact on performance – at least, it’s much smaller than what we were expecting. A very convincing explanation is that the higher frequency of GCs is reducing the number of things that are being destroyed each GC. So now we have smaller and more frequent garbage collections.

EDIT: Looks like people need more clarification here, since the comments about it are just plain wrong. I’ll be technical, and precise – if you don’t understand, please do some research. The garbage collector is scheduled every time a GObject wrapped in GJS has its toggle reference gone from >1 to 1. And scheduled here means that a GC is injected into the mainloop as an idle callback, that will be executed when there’s nothing else to be executed in the mainloop. The absolute majority of the time, it means that only one GC will happen, even if hundreds of GObjects are disposed. I’ve spotted in the wild it happening twice. This fix is strictly specific to GObjects wrapped by GJS; all other kinds of memory management, such as strings and whatever else, aren’t affected by this fix. Together with this patch, an accompanying solution landed that reduces the number of objects with a toggle reference.

This obviously needs more testing on a wider ranger of hardwares, specially on lower ends. But, quite honestly, I’m personally sure that this apparently small performance penalty is compensated by the memory management gains.

Other Improvements

While the previous section covered my side of this history, there are a few other contributors that did a great job, and I think it would be unfair with them if their work was not properly highlighted.

Red Hat’s Carlos Garnacho published two merge requests for GJS that, in my testing, substantially improved the smoothness of GNOME Shell. The first one changes the underlying data structure of JS objects, which allows us to stop using an O(n) algorithm and starting an O(1) one. The second one is particularly interesting, and it yields the most noticeable improvements in my computer. Gross, it vastly reduces the number of temporary memory allocations. He also has a number of patches on Mutter and GNOME Shell.

Another prominent contributor regarding performance is Canonical’s Daniel van Vugt, which helped early testing the GJS patches, and is doing some deep surgeries in Mutter to make the rendering smoother.

And for every great contributor, there is a great reviewer too. It would be extremely unfair if those relevant people haven’t had their work valued by the community, so please, take a moment to appreciate their work. They deserve it.

Final Thoughts

At this point, hopefully the cautious reader will have at least a superficial knowledge on the problem, the solution, and other relevant work around the performance topic. Which is good – if I managed to communicate that well enough, by the time you finish reading this blog post, you’ll have more knowledge. And more knowledge is good.

You can stop here if you want nothing more than technical knowldedge.

Still around?

Well, I’d like to raise an interesting discussion about how people reacted to the memory leak news, and reflect upon that. By reading the repercussions of the news, I found it quite intriguing to read comments like these:

weird comment 1

Captura de tela de 2018-04-20 22-51-53

Captura de tela de 2018-04-20 22-52-17

As a regular contributor for the last few years, this kind of comment sound alien to me. These comments sound completely disconnected to the reality of the development process of GNOME. It completely misses the individuality of the people involved. Maybe because we all know each other, but it is just plain impossible to me to paint this whole community as “they”; “GNOME developers”; etc. To a deeper degree, it misses the nuances and the beauty of community-driven development, and each and every individual that make it happen.

To some degree, I think this is a symptom of users being completely disconnected to GNOME development itself.

It almost feels like there’s a wall between the community and the users of what this community produces. Which is weird. We are an open community, with open development, no barriers for new contributors – and yet, there is such a distance between the community of users and the community of developers/designers/outreachers/etc.

Is that a communication problem from our side? How can we bridge this gap? Well, do we want to bridge this gap? Is it healthy to reduce the communication bandwidth in order to increase focus, or would it be better to increase that and deal with the accompanying noise?

I would love to hear your opinions, comments and thoughts on this topic.

How I became a GNOME contributor

Recently, I was asked by my fellow GNOME friends to write how did I transitioned from nothing to a GNOME contributor. The intention is to motivate people to engage. I don’t think my story is that exciting, but, well, why not? If someone gets motivated and start contributing, goal achieved. But beware: there ain’t any TL;DR here. it’s just a long story.

So, where should I start?

From Childhood to Early Contributions

My relationship with computers began at early age, since I was literate by my parents using an old computer we gained from a relative. I remember searching “how to create exe files” around 2004, and that search result yelled me a Yahoo! Answers question with “you need to learn a programming language. Start with C”.

And so I did.

My first app was a command line calculator. Moving to Linux was a natural step. And that introduced me to GNOME, and Gtk+. By that time, Gtk+ was still 2.6. I did some small apps for personal use, like an app to track new habits. Unfortunately, those apps are long gone.

And that’s how it all started.

Translations…

Fast forward some years and, one day, while using a GNOME app (can’t remember which one!), I saw an unstranslated string! I researched a bit and found out that I could translate and contribute to the Brazilian Portuguese translation team. This was 2012, GNOME 3 was just released, everybody were still very angry, things were very confusing.

My first upstream contributions back to the end of 2012, fixing and adding some missing translations.

At that time, there was one project that draw my attention: a new, unreleased app called GNOME Calendar. It was under heavy development in a branch called ui-review, no packages were available… and yet, I simply loved it. The developer, Erick Perez, is highly skilled. This app was a hidden gem.

Unfortunately, development of Calendar stalled and I spent more than 1 year checking the logs almost every day, waiting for changes.

They never came.

… and GNOME Calendar

“This project was too good to die”, I thought. “I have to do somthing.” First, I tried to finish the design specs of Calendar. You can still find it in my DeviantArt page (click here to check it out).

Then I ran Gedit, opened some files and started hacking Calendar. My very first work was on the Week view prototype we had in there. The video of this new feature is still available:

Notice that the second article of this blog talks about that 🙂

Erick saw that, sent me an email, I attached some patches to Bugzilla, and this is how I officially started contributing to GNOME. At the same year, GNOME Calendar had its first release ever – and this makes the third article of this blog.

GNOME Foundation and Google Summer of Code

After increasing my contribution rate at GNOME Calendar, Erick suggested me to get a Foundation membership. In Januray 2015, I applied and was accepted (yay!!). At the same year, I decided to apply for a Google Summer of Code project at Nautilus. The mentor was Carlos Soriano.

The GSoC project was very successfull, and not only Nautilus received the improvements, but also Gtk+ itself. This is when the “Other Locations” view was introduced, and a big code refactor landed (and allowed Nautilus to improve much more!)

Captura de tela de 2015-12-11 02-45-11
The results of that Summer of Code project

Fun fact: while organizing the tasks of the GSoC, I couldn’t find any personal task manager for GNOME that satisfied me. I took one week and create GNOME To Do to organize my tasks.

With that done, the only step left was presenting that work at GUADEC.

GUADEC and Endless

The presentation at GUADEC was good enough, and meeting the people behind GNOME was one of the most remarkable experiences in my life. At that GUADEC, I met Cosimo, who works at Endless. I remember he downloading the new Gtk+ version and saying “look at this cute ‘Other Locations’ button!” (!!!) 🙂

A few weeks after that, I was contacted by Endless, where I am up to this day. Here at Endless, I’m lucky enough to be able to work upstream almost by default. I’m also happy to be able to make GNOME (through Endless OS) reach more people around the world.

What’s next?

New Control Center, more features in Calendar and To Do, and some other surprises I’ll write about in the future 🙂

Core Apps Hackfest afterthoughts

During last weekend, I was very happy to attend the Core Apps Hackfest in Berlin. This is effectively the first hackfest I’ve ever been! Thanks Carlos for organizing that, thanks Kinvolk folks for hosting the event, and Collabora for sponsoring the dinner.

This event was a great chance to meet the maintainers in person and talk directly to the designers about doubts we have. Since Carlos already wrote down the list of tasks we worked on, I’m not going to repeat it. So here, I’ll report what I was able to work on.

App-specific discussion

GNOME Music

Together with Marinus and Felipe, we were able to give GNOME Music some thought and decide what to do next. Music, unfortunately, was not written to scale, and this is basically the worst blocker we have to deal with. Pieces of code are not contained, and working on something means breaking something else completely unrelated.

So we sit down and analyzed the code, and came up with a solution for that. Music needs to isolate the backend and the UI, so we can write extensions to music providers in such a way that the UI doesn’t have to be patched too much for that. We decided to work on it before trying to add any new features, because otherwise GNOME Music will be unmaintainable.

For the next release, do expect to see lots of action in Music’s codebase, but few features. Most of the efforts will be focused on refactoring and cleaning the code (even if that means more lines of code in the end).

GNOME Calendar

I’ve been able to work on top of Vamsi’s previous prototype of the week view a little bit, and it’s starting to take shape. Basically, getting a working week view is hard. I’m sure we’ll be able to have something working by the end of December, but I expect some pain and headaches before getting into that state.

Andreas also did a quick live testing of GNOME Calendar, and I could see a few bugs to be fixed.

Nautilus

What a great chance to talk about our beloved shellfish! With Carlos and Alex in there, some issues were figured out and hammered off.

We also dicussed the plans for porting Nautilus to GtkListBox and GtkFlowBox. The biggest problem with those widgets is scalability: they’re not performant on big ammounts of data. Put 10k rows inside a listbox and it slows down to death. Same for flowbox.

Following up on the discussion, the flowbox-based view prototype that Carlos did some time ago was rebased against master. I also worked on rebasing the actionbar prototypes against master. From now on, I’ll focus on trying to get the actionbars into the main codebase.

Generic discussions

As Allan detailed in his report, one of the big app-agnostic concepts discussed in this event was the content apps opening and managing files.

I somehow got involved a lot with GNOME Music development, so we discussed how can GNOME Music handle that. We ultimately realized that it’d be better for everyone if we do it The Right Way © and land the code refactorings and backend work before even attempting to do that. This will avoid having to implement the feature twice (before and after the refactoring) and frustrating people with eventual breakages.

This won’t affect GNOME Calendar nor GNOME To Do at the moment, so this discussion wasn’t my focus.

Some Highlights

There’s a bunch of things that happened during the hackfest that I’d like to highlight:

  1. The always-awsome Carlos Garnacho fixed some locking issues in Tracker that gave another performance boost to GNOME Music. Now I can really use Music as my everyday player. It takes only 2 or 3 seconds to load my 10.000-songs library.
  2. The new Online Accounts panel patches were reviewed, and started to land on the main codebase. Thanks Rishi!
  3. The GNOME hackers are absolutely awsome. They’re great people, really. I’m proud and honored to be part of this team with such incredible people. I feel like a small kid both in technical and human terms when with them.

I’m very grateful for the GNOME Foundation for sponsoring me. I wouldn’t be able to attend without the sponsorship. And I also thank Endless for allowing me to attend the event. This event was very productive and I have a strong feeling that this really pays back to the community.

sponsored-badge-shadow

I’m going to the Core Apps Hackfest

In this exact moment, I’m packing up my stuff to attend the Core Apps Hackfest organized by Carlos Soriano and kindly hosted by Kinvolk. It’ll happen in Berlin, German.

I have mixed feelings about this trip.

The Good:

  • I’m super excited to see old friends again. Do you guys remember Carlos was my GSoC mentor? Kudos for him for he organized this event, I want to see you again dude!
  • Looks like Berlin is a great place to be and, even though this is a focused trip, I want to quickly visit one or two historical places.
  • This hackfest has an incredibly high potential to be productive. Major core contributors will be there.
  • I’m positively surprised that my sponsorship request was accepted. Traveling from Brazil is very expensive. I can’t thank the GNOME Foundation enough for that. I really wouldn’t be able to attend without it.
  • That’s a great oportunity to get some fresh winter German air. There’s a chance I’ll see snow for the first time ever (ya’ know, Brazil has no snow…).
  • Even if the average German consumes a lot of meat, appearently there is an unbelievably high number of veg(etari)an restaurants nearby.

The Bad:

  • It’s cold. I lived my entire life in a place where the worst possible weather is worth a jacket. I’m talking about the possibility of snow. Frozen water falling from the damn sky.
  • I really hope I can be productive. The last few weeks of my life were insane, and my performance is not at its peak. I want every single cent spent by the GNOME Foundation on me to be worth it.
  • I also hope that Endless benefits from this hackfest’s outcome.
  • I don’t speak Dutch. I don’t know how receptive they’ll be with a foreigner in their country that doesn’t speak a single word in their language. (Sorry folks.)
  • I’ll miss my wife!

Of course, even if I have some fears, I’m extremely happy with this hackfest. Thanks again for the GNOME Foundation for sponsoring me, and thanks Endless for allowing me to attend it.

banner down

sponsored-badge-shadow

CSS blend modes in Gtk+

As part of my work on Endless, I have to maintain and adapt GNOME applications to better suit our needs. This usually includes fixing bugs, working around limitations of the toolkit, and sometimes implementing new features.

Some time ago, I was asked by multiple designers about the CSS blending modes. This is a well-known feature that is widely used in photo manipulation apps like Photoshop®, and recently Adobe is trying to port this to CSS3 spec.

This allows designers to be more flexible and have a finer control over the rendering, and saves some bandwidth because we don’t have to send the blended image as an asset.

This marvelous feature is starting to see its light in Gtk+.

Captura de tela de 2016-07-03 11-45-06
Background blend mode is about to land.

This is the second time I’m working on something big on Gtk+ (the first one being the Other Locations view) and I’m pretty excited! This was requested by our beloved designer Lapo and also by Endless designers.

When it lands on master, we’ll also have a nice demo in Gtk3-demo app. And, as tradition dictates, a demo video:

In the near future, I plan to work and support more blending operations and CSS properties. Hopefully, this puts Gtk+ ahead of many browsers that doesn’t support these operations. What do you think? Share your comments, ideas and suggestions! 🙂

Endless joined GNOME Advisory Board

Right after I wrote about my unexpected dream hacking routine at Endless, an intriguingly positive news arose: Endless joined GNOME Advisory Board, and I particularly think I should talk about that. That’s old news, but important nevertheless.

Let’s start.

Why does it matter?

Endless is intimately connected to GNOME. We extensively use the GNOME stack, and our apps are based on GNOME technology like GJS, GLib, Gtk+ and others. The spirit of Endless is to upstream as much as it can.

By joining the Advisory Board, Endless formally states that it supports GNOME. “Formally” because it was already rooted in the very essence on Endless for quite some time – many GNOME contributors (including me) work on Endless. Endless supports and motivates us to keep doing upstream work.

By growing the number of sponsors, GNOME Foundation calls attention. It’s an open door to make a difference.

A win-win situation

I’m really happy with the alignment between GNOME and Endless. Both teams end up winning on this game.

As a GNOME contributor, it is really satisfying to see it running on custom hardware. A GNOME-based OS, reaching people who never had contact with technology! More people knowing GNOME increases the number of potential contributors. If 0.1% of GNOME users ends up turning into contributors, and Endless wants, say, 1 billion users, that’s 10,000 potential contributors. Endless gives users and potential contributors for GNOME.

As an Endless employee that believe in it’s mission, using GNOME as the base of the system is cheap and easy. We don’t have to maintain applications, we just consume what’s already there – and obviously push it upstream when it makes sense. Also, we benefit from contributors’ work on the apps. GNOME gives a stable and amazing plataform for us.

In the end, GNOME benefits from Endless, and Endless benefits from GNOME. It’s a lovely relationship.

banner down

How’s my hacking routine at Endless

As some of you may know, I’m working with Endless for some months now. It probably is a cultural shock, but they exceed every aspect I’ve imagined. If you dear reader is not aware of what Endless is and does, I strongly suggest you to go to endlessm.com and check it out. Believe me, it’s worth the time.

I usually have to deal with some daily things: martial arts training, chores, mastering research, wife, among other less important stuff. My first surprise: in terms of work, this doesn’t matter. As long as I’m able to handle my tasks, it’s not required to work from X a.m. to Y p.m. nor my workflow is enforced.

A second to explain some cultural curiosities: here in Brazil, it’s absolutely normal for an employer to set up the exact time an employee must arrive, leave, break, talk, breathe and anything else you can do besides working. Also, one should expect a daily 2h travel to reach the workplace, usually accompanied by the 3rd (Rio de Janeiro) or 7th (São Paulo) worst traffic worldwide.

After adapting to my new routine, it is quite common for a day to run like this: wake up, do my chores, turn on my laptop and work for some hours. After lunching, some more work, study and research, train hard, work some more and sleep.

But why am I writing this? Because I’m so, so happy with this routine. I just arrived home after removing the last bits of a surgery, and I can work. And it’s something I love. I’d be doing this work even without payment.

That said, let’s return to our lives 🙂

I’m joining Endless

Some of you may have asked why I’m so silent for the last 3 weeks. Well, the titles pretty much explain things: between university duties, moving to a new house and conducting my research, I’m also joining Endless!

I’m ridiculously happy with this opportunity, and Endless folks were extremely respectful of my schedule – I’m working remotely, and only as a part-time intern. This is a great chance for me to work with FOSS on something that directly changes people’s lives!

So, wait for 2 more weeks so I can settle again, and I’ll start sending patches and crafting new features on rampage – like the good ol’ times.